Messages in this thread | | | Date | Mon, 27 Mar 2006 11:38:26 +0200 | From | Zoltan Menyhart <> | Subject | Re: unlock_buffer() and clear_bit() |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |