From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [patch 00/52] vfs scalability patches updated Date: Fri, 2 Jul 2010 03:23:17 +1000 Message-ID: <20100701172317.GB1830@laptop> References: <20100624030212.676457061@suse.de> <20100630113054.GL24712@dastard> <20100630124049.GH21358@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, John Stultz , Frank Mayhar , Linus Torvalds To: Dave Chinner Return-path: Content-Disposition: inline In-Reply-To: <20100630124049.GH21358@laptop> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jun 30, 2010 at 10:40:49PM +1000, Nick Piggin wrote: > But actually it's not all for scalability. I have some follow on patches > (that require RCU inodes, among other things) that actually improve > single threaded performance significnatly. git diff workload IIRC was > several % improved from speeding up stat(2). I rewrote the store-free path walk patch that goes on top of this patchset (it's now much cleaner and more optimised, I'll post a patch soonish). It is quicker than I remembered. A single thread running stat(2) in a loop on a file "./file" has the following cost (on an 2s8c Barcelona): 2.6.35-rc3 595 ns/op patched 336 ns/op stat(2) takes 56% the time with patches. It's something like 13 fewer atomic operations per syscall. What's that good for? A single threaded, cached `git diff` on the linux kernel tree takes just 81% of the time after the vfs patches (0.27s vs 0.33s).