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

[John Ogness <dazukocode@ogness.net>]

On 2008-11-12, Eric Paris <eparis@redhat.com> wrote:
> 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

Can you provide the number of calls into the listeners for each type of
fanotify event? It would provide a better picture of the scope of the
issue.

I find your non-fastpath numbers quite alarming.

The DazukoFS stackable filesystem can also be used for userspace
listeners to acknowledge/handle filesystem events. (I only mention
DazukoFS here so that there is some kind of metric comparison that can
be used.) I find a 15% overhead in communication to be too
expensive. And a 934.7% performance hit is... well...

The DazukoFS stackable filesystem only provides file open events, but
its numbers may still be of interest here:

kernel build on tmpfs:          72m36.884s
kernel build on tmpfs+DazukoFS: 75m30.569s

That is an overhead of 4%. Your results show that fanotify (with
fastpaths!) has an overhead of 15%.

My test was done using Linux 2.6.32 and DazukoFS 3.1.2. The Linux source
and build were located on tmpfs to minimize hard drive hits. The machine
was a 600MHz PowerPC, which is why the build times were so long.

During the test, the DazukoFS listeners recorded a total of 991,907 file
open events.

IMHO event filtering should happen in userspace. My experience is that
the context switches can be quite cheap. Perhaps if we know which
fanotify events (and how many) occur within your test, we can begin to
understand why your results are what they are.

John Ogness