On Friday 19 October 2007 11:21, Christoph Lameter wrote: > On Fri, 19 Oct 2007, Nick Piggin wrote: > > Ah, thanks, but can we just use my earlier patch that does the > > proper __bit_spin_unlock which is provided by > > bit_spin_lock-use-lock-bitops.patch > > Ok. > > > This primitive should have a better chance at being correct, and > > also potentially be more optimised for each architecture (it > > only has to provide release consistency). > > Yes that is what I attempted to do with the write barrier. To my knowledge > there are no reads that could bleed out and I wanted to avoid a full fence > instruction there.
Oh, OK. Bit risky ;) You might be right, but anyway I think it should be just as fast with the optimised bit_unlock on most architectures. Which reminds me, it would be interesting to test the ia64 implementation I did. For the non-atomic unlock, I'm actually doing an atomic operation there so that it can use the release barrier rather than the mf. Maybe it's faster the other way around though? Will be useful to test with something that isn't a trivial loop, so the slub case would be a good benchmark. - 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/