Messages in this thread |  | | Date | Fri, 22 Sep 2000 11:08:21 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: GCC proposal for "@" asm constraint |
| |
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/
|  |