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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150622151121.GK3913@linux.vnet.ibm.com>
Date:	Mon, 22 Jun 2015 08:11:21 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Dave Hansen <dave@...1.net>, Andi Kleen <ak@...ux.intel.com>,
	dave.hansen@...ux.intel.com, akpm@...ux-foundation.org,
	jack@...e.cz, viro@...iv.linux.org.uk, eparis@...hat.com,
	john@...nmccutchan.com, rlove@...ve.org,
	tim.c.chen@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched
 files

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/