Re: [PATCH =-v3 07/21] fanotify: fastpath to ignore certain incore inodes

[Eric Paris]

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.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/