From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Mayhar Subject: Re: VFS scalability git tree Date: Tue, 14 Sep 2010 16:02:32 -0700 Message-ID: <1284505352.26440.7.camel@bobble.smo.corp.google.com> References: <20100722190100.GA22269@amd> <20100730091226.GA10437@amd> <1280795279.3966.47.camel@localhost.localdomain> <20100803054400.GA7398@amd> <20100914222612.GA23871@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Nick Piggin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Christoph Hellwig Return-path: In-Reply-To: <20100914222612.GA23871@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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 Google, Inc.