On Fri, 19 Oct 2007, Nick Piggin wrote: > > 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.
How expensive is the fence? An store with release semantics would be safer and okay for IA64. > 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. Lets avoid mf (too expensive) and just use a store with release semantics. Where can I find your patchset? I looked through lkml but did not see it. - 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/
