Zoltan Menyhart wrote:
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()"...
Now I could be wrong here, but it looks like ia64's
smp_mb__after_clear_bit is broken.
There is nothing in any of the memory barrier, bitop, or atomic
operations that says anything about aquire or release semantics.
The only memory barriers with those semantics currently are those
implied by locking operations.
smp_mb__after_clear_bit() is supposed to, when run directly after
a clear_bit operation, provide the equivalent of an smp_mb().
If you actually need a memory barrier _before_ the clear_bit
(ie. that orders the clear_bit with previous stores) operation,
then you have to issue a seperate barrier completely. Likewise
for a barrier after clear_bit.
The problem with ia64 is that its atomic operations always either
imply aquire or relese semantics, so acquire is simply chosen
arbitrarily. So what I think you should do is make both
smp_mb__before and after_clear_bit issue at least a release
consistency instruction -- combined I think they provide a full
barrier, regardless of their order?
--
SUSE Labs, Novell Inc.
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
