linux-kernel - Re: Why Semaphore Hardware-Dependent?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Sep 2006 04:04:35 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	David Howells <dhowells@...hat.com>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Dong Feng <middle.fengdong@...il.com>, ak@...e.de,
	Paul Mackerras <paulus@...ba.org>,
	Christoph Lameter <clameter@....com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Why Semaphore Hardware-Dependent?

David Howells wrote:
> Nick Piggin <nickpiggin@...oo.com.au> wrote:
> 
> 
>>I wonder if we can just start with the nice powerpc code that uses
>>atomic_add_return and cmpxchg (should use atomic_cmpxchg)
> 
> 
> Because i386 (and x86_64) can do better by using XADDL/XADDQ.

I mean cmpxchg for the cmpxchg part. atomic_add_return already uses
xadd (for i386, or eg. a fetchadd on ia64).

>>and chuck out the "crappy" rwsem fallback implementation,
> 
> 
> CMPXCHG is not available on all archs, and may not be implemented on all archs
> through other atomic instructions.

atomic_cmpxchg is available on all architectures.

>>as well as all the arch specific code?
> 
> 
> Using CMPXCHG is only optimal where that's the best available.

If this following patch is one or two cycles slower on some architectures
when everything is hot in cache and you're going down hill, then it is
still going to be faster overall due to being 22 icache lines smaller on
my SMP PIII kernel.

Also, the code sharing and complexity reduction IMO would be worth it
anyway even if it was slightly slower (unless that proved to be
significant on any real workload).

Anyway, this is my proposal for a generic rwsem. IMO this is a good place
to start from scratch, and if any arch really needs specific code, then we
can look at making a sane abstraction for them.

Comments?

-- 
SUSE Labs, Novell Inc.

View attachment "rwsem-generic.patch" of type "text/plain" (86730 bytes)