linux-kernel - Re: VFS scalability git tree

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]

Message-ID: <1284505352.26440.7.camel@bobble.smo.corp.google.com>
Date:	Tue, 14 Sep 2010 16:02:32 -0700
From:	Frank Mayhar <fmayhar@...gle.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Nick Piggin <npiggin@...e.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: VFS scalability git tree

On Tue, 2010-09-14 at 18:26 -0400, Christoph Hellwig wrote:
> Nick,
> 
> what's the plan for going ahead with the VFS scalability work?  We're
> pretty late in the 2.6.36 cycle now and it would be good to get the next
> batch prepared and reivew so that it can get some testing in -next.
> 
> As mentioned before my preference would be the inode lock splitup and
> related patches - they are relatively simple and we're already seeing
> workloads where inode_lock really hurts in the writeback code.

For the record, while I've been quiet here (really busy) I have run a
bunch of pretty serious tests against the original set of patches (note:
_not_ the latest bits in Nick's tree, I have those queued up but haven't
gotten to them yet).  So far I haven't seen any instability at all.

(I did see one case in which a test that does a _lot_ of network traffic
with tons of sockets saw a 20+% performance hit on a system with a
relatively moderate number of cores but I haven't had the time to
characterize it better and want to test against the newer bits in any
event.  Sorry to be so vague, I can't really be more specific at this
point.  Nailing this down is _also_ on my list.)

Performance notwithstanding, I'm impressed with the stability of those
original patches.  I've run VM stress tests against it, FS stress tests,
lots of benchmarks and a bunch of other stuff and it's solid, no crashes
nor any anomalous behavior.

That being the case, I would vote enthusiastically for bringing in the
inode_lock splitup as soon as is feasible.
-- 
Frank Mayhar <fmayhar@...gle.com>
Google, Inc.

--
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/