Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions

[Nick Piggin <nickpiggin@yahoo.com.au>]

Satyam Sharma wrote:
> On Tue, 24 Jul 2007, Nick Piggin wrote:

> > > > Are you saying that it is OK for the store to var to
> > > > be reordered below the clear_bit? If not, what are you
> > > > saying?
> > >
> > >
> > > I might be making a radical turn-around here, but all of a
> > > sudden I think it's actually a good idea to put a complete
> > > memory clobber in set_bit/clear_bit and friends themselves,
> > > and leave the "__" variants as they are.
> >
> > Why?
>
>
> Well, why not. Callers who don't want/need any guarantees whatsoever
> can still use __foo() -- for others, it makes sense to just use
> foo() and get *both* the compiler and CPU barrier semantics -- I think
> that's the behaviour most callers would want anyway.

Firstly, __foo() is non-atomic, secondly set_bit/clear_bit/etc do not
provide any CPU or compiler semantics.

It was set up this way because other CPU ISAs don't couple atomicity
with memory ordering, and with many implementations of those, the cost
to order memory is quite high.

--
SUSE Labs, Novell Inc.
-
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/