Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Hansen <dave@sr71.net>, Andi Kleen <ak@linux.intel.com>,
	dave.hansen@linux.intel.com, akpm@linux-foundation.org,
	jack@suse.cz, viro@zeniv.linux.org.uk, eparis@redhat.com,
	john@johnmccutchan.com, rlove@rlove.org,
	tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files
Date: Mon, 22 Jun 2015 08:11:21 -0700	[thread overview]
Message-ID: <20150622151121.GK3913@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150622132821.GB12596@twins.programming.kicks-ass.net>

On Mon, Jun 22, 2015 at 03:28:21PM +0200, Peter Zijlstra wrote:
> On Sat, Jun 20, 2015 at 06:30:58PM -0700, Paul E. McKenney wrote:
> > Well, it is not hard to have an SRCU-like thing that doesn't have
> > read-side memory barriers, given that older versions of SRCU didn't
> > have them.  However, the price is increased latency for the analog to
> > synchronize_srcu().  I am guessing that this would not be a problem
> > for notification-group destruction, which is presumably rare.
> 
> I don't think it ever makes sense to optimize for a global state. So
> screw sync_srcu() and make the srcu_read_lock() thing go fast.
> 
> If you need fast global state you're doing it wrong.

That depends on how slow the resulting slow global state would be.
We have some use cases (definitely KVM, perhaps also some of the VFS
code) that need the current speed, as opposed to the profound slowness
that three trips through synchronize_sched() would provide.  Plus we
would lose the ability to have SRCU readers on idle and offline CPUs.

But if Dave is willing to test it, I would be happy to send along
a fast-readers patch, easy to do.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/