Re: Fix unlock_buffer() to work the same way as bit_unlock()

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

Christoph Lameter wrote:

> On Tue, 28 Mar 2006, Zoltan Menyhart wrote:
>
>
> > Why not to use separate bit operations for different purposes?
> >
> > - e.g. "test_and_set_bit_N_acquire()" for lock acquisition
> > - "test_and_set_bit()", "clear_bit()" as they are today
> > - "release_N_clear_bit()"...
>
> That would force IA64 specifics onto all other architectures.
>
> Could we simply define these smb_mb__*_clear_bit to be noops
> and then make the atomic bit ops to have full barriers? That would satisfy 
> Nick's objections.

Well yes, I think the current operations should not be changed because
that would probably require large and difficult audits of the tree.

However, I think it might be reaonsable to use bit lock operations for
in places like page lock and buffer lock (ie. with acquire and relese
semantics). It improves ia64 without harming other architectures, and
also makes the code more expressive.

> Index: linux-2.6.16/include/asm-ia64/bitops.h
> ===================================================================
> --- linux-2.6.16.orig/include/asm-ia64/bitops.h	2006-03-19 21:53:29.000000000 -0800
> +++ linux-2.6.16/include/asm-ia64/bitops.h	2006-03-28 15:45:08.000000000 -0800
> @@ -45,6 +45,7 @@
> 		old = *m;
> 		new = old | bit;
> 	} while (cmpxchg_acq(m, old, new) != old);
> +	smb_mb();
> }

Can this allow the actual bitop to move up past previous memory ops?
Would it be sufficient to just put a release barrier above the acquire
barrier?

--

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/