From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount Date: Fri, 30 Aug 2013 09:16:12 +0200 Message-ID: <20130830071612.GB14099@gmail.com> References: <1375758759-29629-1-git-send-email-Waiman.Long@hp.com> <1375758759-29629-2-git-send-email-Waiman.Long@hp.com> <1377751465.4028.20.camel@pasglop> <20130829070012.GC27322@gmail.com> <1377822408.4028.44.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Benjamin Herrenschmidt , Waiman Long , Alexander Viro , Jeff Layton , Miklos Szeredi , Ingo Molnar , Thomas Gleixner , linux-fsdevel , Linux Kernel Mailing List , Peter Zijlstra , Steven Rostedt , Andi Kleen , "Chandramouleeswaran, Aswin" , "Norton, Scott J" , Michael Neuling To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org * Linus Torvalds wrote: > > BTW. Do you have your test case at hand ? > > My test-case is a joke. It's explicitly *trying* to get as much > contention as possible on a dentry, by just starting up a lot of threads > that look up one single pathname (the same one for everybody). It > defaults to using /tmp for this, but you can specify the filename. Waiman's tests seemed to use sufficiently generic and varied workloads (AIM7) and they showed pretty nice unconditional improvements with his variant of this scheme, so I think testing with your simple testcase that intentionally magnifies the scalability issue is 100% legit and may in fact help tune the changes more accurately, because it has less inherent noise. And that was on a 80 core system. The speedup should be exponentially more dramatic on silly large systems. A nicely parallel VFS isn't a bad thing to have, especially on ridiculously loud hardware you want to run a continent away from you. Thanks, Ingo