Christoph Lameter wrote on Tuesday, March 28, 2006 4:47 PM
> > Why not make unlock_buffer use test_and_clear_bit()? Utilizing it's implied
> > full memory fence and throw away the return value? OK, OK, this is obscured.
> > Then introduce clear_bit_memory_fence API or some sort.
>
> Only for IA64's sake? Better clean up the bitops as you suggested earlier.
> The open ended acquires there leaves a weird feeling.
>
> Something like this? (builds fine not tested yet)
It's warm and fuzzy feeling with changes in set_bit(), clear_bit(), and
change_bit(). The API never meant to have implied memory fence in them.
Though the usage might be assuming one way or the other because of x86
semantics.
How many of these things are used as (1) simple atomic op, (2) lock,
(3) unlock, and (4) full fence?
clear_bit - 1,070 hits
Set_bit - 1,450 hits
Change_bit - 8 hits
The effect of changing them to full memory fence could be wide spread. Though
I don't have any numbers yet to say how much it will matter for performance.
- Ken
-
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]
