Christoph Lameter wrote:
Hmmm... Maybe we therefore need to add a mode to each bit operation in
the kernel?
With that we can also get rid of the __* version of bitops.
Possible modes are
NON_ATOMIC Do not perform any atomic ops at all.
ATOMIC Atomic but unordered
ACQUIRE Atomic with acquire semantics (or lock semantics)
RELEASE Atomic with release semantics (or unlock semantics)
FENCE Atomic with full fence.
This would require another bitops overhaul.
Maybe we can preserve the existing code with bitops like __* mapped to
*(..., NON_ATOMIC) and * mapped to *(..., FENCE) and the gradually fix the
rest of the kernel.
Form semantical point of view, the forms:
bit_foo(..., mode)
and
bit_foo_mode(...)
are equivalent.
However, I do not think your implementation would be efficient due to
selecting the ordering mode at run time:
+ switch (mode) {
+ case MODE_NONE :
+ case MODE_ACQUIRE :
+ return cmpxchg_acq(m, old, new);
+ case MODE_FENCE :
+ smp_mb();
+ /* Fall through */
+ case MODE_RELEASE :
+ return cmpxchg_rel(m, old, new);
+ if (mode == ORDER_NON_ATOMIC) {
+ *m |= bit;
+ return;
+ }
etc.
In addition, we may want to inline these primitives...
A compile-time selection of the appropriate code sequence would help.
Thanks,
Zoltan
-
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]
