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-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Mar 30 19:44:19 2006
This archive was generated by hypermail 2.1.8 : 2006-03-30 19:44:29 EST