fanotify: fastpath to ignore certain in core inodes
in [Kernel]
|
Prev: [PATCH v9 2/8] Loongson: YeeLoong: add platform driver
Next: [PATCH] vbus: fix lots of sparse "dubious signed bitfield" warnings
From: John Ogness on 8 Dec 2009 10:30 On 2008-11-12, Eric Paris <eparis(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |