On Fri, 22 Sep 2000, Andrea Arcangeli wrote:
>
> If you don't like the name smp_mb__before/after_clear_bit (not that I like it
> too much too) suggestions are welcome. Maybe we could use a single
> smp_mb__across_bitops() instead?
I suspect that we should just split up the bitops.
We've done this once already. We used to have just one set of bitops that
always returned the old value, and it was inefficient when many users
don't actually care and you can often do it faster if the return value
doesn't matter. Thus the (long ago) split of "set_bit()" to "set_bit()"
and "test_and_set_bit()".
These days we have similar issues. In many cases we don't even want the
SMP safety - we just want to set a bit, and we already do locking. This
shows up in the mm code, for example - we use test_and_change_bit() for
the buddy allocator, and it doesn't have to be atomic because we have to
have locking for other reasons anyway. So on x86 we basically waste cycles
on locked accesses several times for each alloc/free page.
The same is true in the filesystems - many of them want to change block or
inode allocation bitmap bits, but they have to hold a lock anyway (usually
the kernel lock in addition to the superblock lock.
And in some circumstances (page locking, possible buffer cache locking)
you obviously do want the memory barrier stuff, and you're right, making
it associated with the bit operations allows for faster code on x86 where
the locked bit ops are barriers in themselves.
Ugh. There's quite a lot of combinations there. Maybe your approach is the
cleanest one.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:27 EST