Zoltan Menyhart wrote:
4. Bit-lock operations:
I summarized the ordering requirements here:
http://marc.theaimsgroup.com/?l=linux-ia64&m=114362989421046&w=2
In order to let the architectures implement these bit-lock
operations efficiently, the usage has to indicate the _minimal_
required ordering semantics, e.g.:
test_and_set_bit_N_acquire()
or ordered_test_and_set_bit(acquire, ...)
release_N_clear_bit()
etc.
The problem is simply that we don't expose acquire or release ordering operations to AI kernel code (outside of locking, which is a great wrapper). The reason is to avoid proliferation of all these semantics. If you do this then the powerpc guys will say they want all their weird crap in there too. If you remove seperate read and write barriers, then x86 and sparc64 folks will get upset etc etc. Changing semantics would probably require some fairly hefty discussions. Can you first fix ia64, then (perhaps) introduce lock semantics for the couple of bitops that can use it, then can we see some performance justification for proposed changes to the API? --Send instant messages to your online friends http://au.messenger.yahoo.com -
: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|