From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.mail.mud.yahoo.com ([209.191.85.215]:24673 "HELO smtp105.mail.mud.yahoo.com") by vger.kernel.org with SMTP id S1750836AbWH2BSt (ORCPT ); Mon, 28 Aug 2006 21:18:49 -0400 Message-ID: <44F395DE.10804@yahoo.com.au> Date: Tue, 29 Aug 2006 11:18:22 +1000 From: Nick Piggin MIME-Version: 1.0 Subject: Re: Why Semaphore Hardware-Dependent? References: <1156750249.3034.155.camel@laptopd505.fenrus.org> In-Reply-To: <1156750249.3034.155.camel@laptopd505.fenrus.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org To: Arjan van de Ven Cc: Dong Feng , ak@suse.de, Paul Mackerras , Christoph Lameter , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, David Howells List-ID: Arjan van de Ven wrote: > On Mon, 2006-08-28 at 03:22 +0800, Dong Feng wrote: > >>Why can't we have a hardware-independent semaphore definition while we >>have already had hardware-dependent spinlock, rwlock, and rcu lock? It >>seems the semaphore definitions classified into two major categories. >>The main deference is whether there is a member variable _sleeper_. > > > btw semaphores are a deprecated construct mostly; mutexes are the way to > go for new code if they fit the usage model of mutexes. And mutexes are > indeed generic (with a architecture hook to allow a specific operation > to be optimized using assembly) That's true, although rwsems are still very important for mmap_sem (if nothing else). There is not yet an rw/se-mutex. rwsem is another place that has a huge proliferation of assembly code. I wonder if we can just start with the nice powerpc code that uses atomic_add_return and cmpxchg (should use atomic_cmpxchg), and chuck out the "crappy" rwsem fallback implementation, as well as all the arch specific code? That would seem to be able to rid us of vast swaths of tricky asm, and also double the test coverage of the out of line lib/ code. Should still generate close to optimal code on i386. The only architectures that might slightly care are those who's atomics hash to locks (in that case, you'd really rather take a lock in the rwsem's cacheline than a random atomic lock... but I don't think incredible parisc/sparc SMP performance is worth the current situation!) -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com