From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org, malware-list@lists.printk.net,
viro@zeniv.linux.org.uk, alan@lxorguk.ukuu.org.uk,
arjan@infradead.org, greg@kroah.com, tytso@mit.edu,
akpm@linux-foundation.org
Subject: Re: [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes
Date: Wed, 12 Nov 2008 23:38:44 +0100 [thread overview]
Message-ID: <1226529524.6696.37.camel@lappy.programming.kicks-ass.net> (raw)
In-Reply-To: <20081112161103.25434.30104.stgit@paris.rdu.redhat.com>
On Wed, 2008-11-12 at 11:11 -0500, Eric Paris wrote:
> +#ifdef CONFIG_FANOTIFY
> + struct list_head fastpath_entries; /* fanotify fastpath entries protected by group */
> + rwlock_t fastpath_rwlock; /* protect the fastpath entries list */
> +#endif
Are you really sure those rwlocks actually gain you performance?
rwlocks are really bad, the critical section must be short because its
non-preemptable, but both the lock and unlock are atomic ops that can
(and usually will) bounce cachelines. So you often get into the
situation where your performance is limited by the cacheline bouncing.
There's also a starvation case in there, where the cacheline is so hot
on one package/node that another package/node doesn't get it.
Regular spinlocks are usually faster in those cases (and on those archs
that have ticket locks avoid the starvation case too).
And for those cases where the read side is long enough to not be
dominated by the cacheline bouncing, RCU is usually the best way out.
next prev parent reply other threads:[~2008-11-12 22:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 16:10 [PATCH =-v3 00/21] fanotify: novel file access notification and permission system Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 01/21] filesystem notification: create fs/notify to contain all fs notification Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 02/21] fsnotify: pass a file instead of an inode to open, read, and write Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 03/21] fanotify: fscking all notify, system wide file access notification Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 04/21] fsnotify: sys_execve and sys_uselib do not call into fsnotify Eric Paris
2008-11-12 16:49 ` Christoph Hellwig
2008-11-12 21:15 ` Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 05/21] fanotify: make use of the new fsnotify_open_exec calls Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 06/21] fanotify: add a userspace interface for fanotify notifications Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes Eric Paris
2008-11-12 16:50 ` Christoph Hellwig
2008-11-12 16:56 ` Alan Cox
2008-11-12 16:58 ` Christoph Hellwig
2008-11-12 20:52 ` Eric Paris
2009-12-08 15:22 ` John Ogness
2008-11-12 22:38 ` Peter Zijlstra [this message]
2008-11-12 16:11 ` [PATCH =-v3 08/21] fanotify: add a userspace interface for fastpaths Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 09/21] fanotify: add group priorities Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 10/21] fanotify: blocking and access granting Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 11/21] fanotify: give a special access permission check Eric Paris
2008-11-12 16:53 ` Christoph Hellwig
2008-11-12 21:23 ` Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 12/21] fanotify: user interface for access decisions Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 13/21] fanotify: ability for userspace to delay responses Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 14/21] fanotify: send pid with fanotify notification events Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 15/21] fanotify: send tgid with notification messages Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 16/21] fanotify: send file f_flags along with notifications Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 17/21] fanotify: add option to clear all fastpaths Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 18/21] fanotify: all userspace to set timeouts Eric Paris
2008-11-12 16:56 ` Christoph Hellwig
2008-11-12 21:14 ` Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 19/21] fanotify: evict misbehaving clients Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 20/21] fanotify: allow fastpath entries to survive inode modification Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 21/21] fanotify: add Documentation Eric Paris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1226529524.6696.37.camel@lappy.programming.kicks-ass.net \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=eparis@redhat.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list@lists.printk.net \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox