Re: unlock_buffer() and clear_bit()

[Zoltan Menyhart]

Andrew Morton wrote:

> This is, I think, a rather inefficient thing we're doing there.  For most
> architectures, that amounts to:
>
> 	mb();
> 	clear_bit()
> 	mb();
>
> which is probably more than is needed.  We'd need to get some other
> architecture people involved to see if there's a way of improving this, and
> unlock_page().

This is why I proposed also:

> > > Or a new bit clearing service needs to be added that includes
> > >   the "rel" semantics, say "release_N_clear_bit()"

The architecture dependent "release_N_clear_bit()" should include what
is necessary for the correct unlocking semantics (and it leaves the freedom
for the "stand alone" bit operations implementations).

Note that "lock_buffer()" works on ia64 "by chance", because all the
atomic bit operations are implemented "by chance" by use of the "acq"
semantics.

I'd like to split the bit operations according to their 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()"...

Thaks,

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