Messages in this thread | | | Subject | Re: [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes | From | Eric Paris <> | Date | Wed, 12 Nov 2008 15:52:29 -0500 |
| |
On Wed, 2008-11-12 at 11:58 -0500, Christoph Hellwig wrote: > On Wed, Nov 12, 2008 at 04:56:38PM +0000, Alan Cox wrote: > > Sounds a good way of ruining the performance. > > I don't think you can ruine performance of a system with AV systems > running even more. While bloating the inode does cause enormous > problems in file serving or other extremly metadata intensive workloads.
Kernel Build on a 32 way machine: Stock kernel: 9 minutes 12 seconds fanotify no in kernel fastpath: 95 minutes 12 seconds Only events AV wants with in kernel fastpath: 10 minutes 35 seconds
Now I could probably redo the in kernel cache as some sort of per group inode hash table of entries which wouldn't have to bloat the inode but it would be much more expensive in terms of performance. A lock and an list if you want to use fanotify is as small as it can be made an is exactly the same method taken by inotify.
************
I probably should have put this up in the patch description rather than burried down in the Documentation directory but here it is:
The need for fastpaths (or calling what it really is, an in kernel cache) has been questioned. I decided to include a little unscientific data here. On a 32 way machine a make -j 32 took about 9 minutes 12 seconds. With that same machine running having one group and 32 listeners receiving every fanotify event that the kernel could send to userspace while the listeners were responding to accesses as fast as they could (just a very tight get event, allow loop) it took 95 minutes 12 seconds. Same process with in kernel fastpaths/cache results took 19 minutes 5 seconds. More reasonable event requirements and a single listener took 10 minutes 35 sec. So about a 15% perf hit to do any kind of permission checking to userspace. Anyway, the need for fastpaths is quite clear.
| |