From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [PATCH 3/3] brlocks/lglocks: turn into functions Date: Mon, 07 May 2012 13:09:04 +0930 Message-ID: <87sjfcfynb.fsf@rustcorp.com.au> References: <87ehtf3lqh.fsf@rustcorp.com.au> <20120227155338.7b5110cd.akpm@linux-foundation.org> <20120228112422.GC11324@alboin.amr.corp.intel.com> <87ipijzfwn.fsf@rustcorp.com.au> <20120420112149.GH25458@amd.local0.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Andrew Morton , Nick Piggin , linux-kernel , Alexander Viro , "Srivatsa S. Bhat" , linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: In-Reply-To: <20120420112149.GH25458@amd.local0.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 20 Apr 2012 21:21:49 +1000, Nick Piggin wrote: > This still not merged? No, I've been away. I've put it in -next for tomorrow, though I'm not sure what the best way to get it to Linus next merge window. > There is a reason, which is performance. Extra function call, but also > IIRC the percpu accessor was not so fast doing it this way. Maybe > that's improved... > > So what's the performance difference? What benchmarks you usually run? Feel free to try it out and report back; I only have small hardware here. > > > > Since there are at least two users it makes sense to share this code in a > > library. This is also easier maintainable than a macro forest. > > > > This will also make it later possible to dynamically allocate lglocks and > > also use them in modules (this would both still need some additional, but > > now straightforward, code) > > Yes, but let's not do either of those things :) > > I was slightly crazy when committing that patch to the kernel, I'll > admit. So if performance isn't significantly affected, then definitely. > If it is... well, it's much easier to gain 1% performance by maintaining > 100 self contained lines of hilarious code like this than to actually > use your brain to improve somewhere else! Cheers, Rusty.