linux-kernel - Re: [PATCH RFC fs] v2 Make sync() satisfy many requests with one invocation

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] [day] [month] [year] [list]

Date:	Tue, 30 Jul 2013 10:43:36 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	davej@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, viro@...iv.linux.org.uk, hch@....de,
	jack@...e.cz, curtw@...gle.com, jaxboe@...ionio.com,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH RFC fs] v2 Make sync() satisfy many requests with one
 invocation

On Mon, Jul 29, 2013 at 05:06:43PM +1000, Dave Chinner wrote:
> On Sat, Jul 27, 2013 at 04:26:28AM -0700, Paul E. McKenney wrote:
> > On Sat, Jul 27, 2013 at 04:21:01PM +1000, Dave Chinner wrote:
> > > On Fri, Jul 26, 2013 at 09:05:24PM -0700, Paul E. McKenney wrote:
> > > > Could you please send your patches over to Dave Jones right now?  I am
> > > > getting quite tired of getting RCU CPU stall warning complaints from
> > > > him that turn out to be due to highly contended sync() system calls.
> > > 
> > > Then ignore them until the code is ready - it'll be 3.12 before the
> > > fixes are merged, anyway, because the lock contention fix requires
> > > infrastructure that is currently in mmotm that is queued for 3.12
> > > (i.e. the per-node list infrastructure) to fix a whole bunch of
> > > other, more critical VFS lock contention problems. Seeing as a new
> > > mmotm went out last week, I should have the patches ready for review
> > > early next week.
> > > 
> > > FWIW, we (as in XFS filesystem testers) regularly run tests that
> > > have hundreds of concurrent sys_sync() calls running at the same
> > > time. e.g. xfstests::xfs/297 runs a 1000 fsstress processes while
> > > freezing and unfreezing the filesystem, and that usually shows
> > > hundreds of threads running sys_sync concurrently after a short
> > > amount of runtime. So it's pretty clear that what Dave is seeing
> > > is not necessarily representative of what happens when there ar lots
> > > of sys_sync() calls run concurrently.
> > 
> > So Dave might be finding an additional problem.  ;-)
> 
> Dave will always find problems. If you want something broken, give
> it to Dave and he'll hand it back in pieces. :)

So rather than Wreck-it Ralph, we have Destroy-it Dave?  ;-)

And I must hasten to add that Dave's destroy-it services, though
sometimes irritating, are almost always quite valuable.

> > > BTW, concurrent syncfs() calls are going to have exactly the same
> > > problem as concurrent sync() calls, as is any other operation that
> > > results in a walk of the per-superblock inodes list.
> > 
> > Yep!  Your upcoming patch addresses these as well?
> 
> Yes, it does.

Good to hear, looking forward to seeing them?

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/