From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Nicolas Pitre <nico@cam.org>,
Joel Schopp <jschopp@austin.ibm.com>, Ingo Molnar <mingo@elte.hu>,
lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Arjan van de Ven <arjan@infradead.org>,
Jes Sorensen <jes@trained-monkey.org>,
Al Viro <viro@ftp.linux.org.uk>, Oleg Nesterov <oleg@tv-sign.ru>,
David Howells <dhowells@redhat.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch@infradead.org>, Andi Kleen <ak@suse.de>,
Russell King <rmk+lkml@arm.linux.org.uk>,
Anton Blanchard <anton@samba.org>
Subject: Re: [patch 00/21] mutex subsystem, -V14
Date: Thu, 05 Jan 2006 14:21:50 +1100 [thread overview]
Message-ID: <43BC90CE.4040201@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0601041847330.3279@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 4 Jan 2006, Nicolas Pitre wrote:
>
>
>>On Wed, 4 Jan 2006, Joel Schopp wrote:
>>
>>
>>>>this is version 14 of the generic mutex subsystem, against v2.6.15.
>>>>
>>>>The patch-queue consists of 21 patches, which can also be downloaded from:
>>>>
>>>> http://redhat.com/~mingo/generic-mutex-subsystem/
>>>>
>>>
>>>Took a glance at this on ppc64. Would it be useful if I contributed an arch
>>>specific version like arm has? We'll either need an arch specific version or
>>>have the generic changed.
>>
>>Don't change the generic version. You should provide a ppc specific
>>version if the generic ones don't look so good.
>
>
> Well, if the generic one generates _buggy_ code on ppc64, that means that
> either the generic version is buggy, or one of the atomics that it uses is
> buggily implemented on ppc64.
>
> And I think it's the generic mutex stuff that is buggy. It seems to assume
> memory barriers that aren't valid to assume.
>
> A mutex is more than just updating the mutex count properly. You also have
> to have the proper memory barriers there to make sure that the things that
> the mutex _protects_ actually stay inside the mutex.
>
> So while a ppc64-optimized mutex is probably a good idea per se, I think
> the generic mutex code had better be fixed first and regardless of any
> optimized version.
>
> On x86/x86-64, the locked instructions automatically imply the proper
> memory barriers, but that was just lucky, I think.
>
I think the generic code is correct according to Documentation/atomic_ops.txt
which basically defines any atomic_xxx operation which both modifies its
operand and returns something to have a full memory barrier before and after
its load/store operations.
Side note, why can't powerpc use lwsync for smp_wmb? The only problem seems to
be that it allows loads to be reordered before stores, but that's OK with
smp_wmb, right?
And why is smp_wmb() (ie. the non I/O barrier) doing eieio, while wmb() does
not? And rmb() does lwsync, which apparently does not order IO at all...
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-01-05 3:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-04 14:41 [patch 00/21] mutex subsystem, -V14 Ingo Molnar
2006-01-04 23:45 ` Joel Schopp
2006-01-05 2:38 ` Nicolas Pitre
2006-01-05 2:51 ` Linus Torvalds
2006-01-05 3:21 ` Nick Piggin [this message]
2006-01-05 3:39 ` Anton Blanchard
2006-01-05 18:04 ` Jesse Barnes
2006-01-05 14:40 ` Ingo Molnar
2006-01-05 16:21 ` Linus Torvalds
2006-01-05 22:03 ` Ingo Molnar
2006-01-05 22:17 ` Linus Torvalds
2006-01-05 22:43 ` Ingo Molnar
2006-01-06 3:49 ` Keith Owens
2006-01-06 7:34 ` Denis Vlasenko
2006-01-05 14:35 ` Ingo Molnar
2006-01-05 16:42 ` Joel Schopp
2006-01-05 22:21 ` Ingo Molnar
2006-01-05 23:06 ` Joel Schopp
2006-01-05 23:26 ` Linus Torvalds
2006-01-05 23:36 ` Joel Schopp
2006-01-05 23:42 ` Ingo Molnar
2006-01-06 0:29 ` Olof Johansson
2006-01-07 17:49 ` PowerPC fastpaths for mutex subsystem Joel Schopp
2006-01-07 22:37 ` Andrew Morton
2006-01-08 7:43 ` Anton Blanchard
2006-01-08 8:00 ` Andrew Morton
2006-01-08 8:23 ` Anton Blanchard
2006-01-09 11:13 ` David Howells
2006-01-08 9:48 ` Ingo Molnar
2006-01-10 22:31 ` Joel Schopp
2006-01-10 23:09 ` Ingo Molnar
2006-01-11 10:52 ` Ingo Molnar
2006-01-11 17:44 ` Joel Schopp
2006-01-08 10:43 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43BC90CE.4040201@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=anton@samba.org \
--cc=arjan@infradead.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=jes@trained-monkey.org \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nico@cam.org \
--cc=oleg@tv-sign.ru \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.