lkml.org 
[lkml]   [2006]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Synchronizing Bit operations V2
Chen, Kenneth W wrote:
> Nick Piggin wrote on Thursday, March 30, 2006 6:53 PM

>>The memory ordering that above combination should produce is a
>>Linux style smp_mb before the clear_bit. Not a release.
>
>
> Whoever designed the smp_mb_before/after_* clearly understand the
> difference between a bidirectional smp_mb() and a one-way memory
> ordering. If smp_mb_before/after are equivalent to smp_mb, what's
> the point of introducing another interface?
>

They are not. They provide equivalent barrier when performed
before/after a clear_bit, there is a big difference.

You guys (ia64) are the ones who want to introduce a new
interface, because you think conforming to the kernel's current
interfaces will be too costly. I simply suggested a way you
could do this that would have a chance of being merged.

If you want to change the semantics of smp_mb__*, then good
luck auditing all that well documented code that uses it.
I just happen to think your best bet is to stick with the
obvious full barrier semantics (which is what other
architectures, eg powerpc do), and introduce something new
if you want more performance.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-31 18:22    [W:0.101 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site