[lkml]   [2008]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes
    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.

     \ /
      Last update: 2008-11-12 21:55    [W:0.048 / U:7.376 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site