linux-kernel - Re: [PATCH 3/3] brlocks/lglocks: turn into functions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sjfcfynb.fsf@rustcorp.com.au>
Date:	Mon, 07 May 2012 13:09:04 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Andi Kleen <ak@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <npiggin@...nel.dk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 3/3] brlocks/lglocks: turn into functions

On Fri, 20 Apr 2012 21:21:49 +1000, Nick Piggin <npiggin@...nel.dk> 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.
--
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/