Re: Synchronizing Bit operations V2

[Christoph Lameter <clameter@sgi.com>]

On Fri, 31 Mar 2006, Nick Piggin wrote:

> This has acquire and release, instead of the generic kernel
> memory barriers rmb and wmb. As such, I don't think it would
> get merged.

Right. From the earlier conversation I had the impression that this is 
what you wanted.
 
> > Note that the current semantics for bitops IA64 are broken. Both
> > smp_mb__after/before_clear_bit are now set to full memory barriers
> > to compensate which may affect performance.
> 
> I think you should fight the fights you can win and get a 90%
> solution ;) at any rate you do need to fix the existing routines
> unless you plan to audit all callers...
> 
> First, fix up ia64 in 2.6-head, this means fixing test_and_set_bit
> and friends, smp_mb__*_clear_bit, and all the atomic operations that
> both modify and return a value.
> 
> Then add test_and_set_bit_lock / clear_bit_unlock, and apply them
> to a couple of critical places like page lock and buffer lock.
> 
> Is this being planned?

That sounds like a long and tedious route to draw out the pain for a 
couple of years and add loads of additional macro definitions all over the 
header files. I'd really like a solution that allows a gradual 
simplification of the macros and that has clear semantics.

So far it seems that I have not even been able to find the definitions for 
the proper behavior of memory barriers.

-
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/