On Wed, 30 Apr 2008, Benjamin Herrenschmidt wrote: > On Tue, 2008-04-29 at 13:36 +0100, Hugh Dickins wrote: > > > > Ugh. It's just so irritating to introduce these blockages against > > such a remote possibility (but there again, that's what so much of > > kernel code has to be about). Is there any other way of handling it? > > Not that much overhead... I think smp_read_barrier_depends() is a nop on > most archs no ? The data dependency between all the pointers takes care > of ordering in many cases. Ah, you're right, I was automatically thinking smp_rmb, whereas as this is the only_does_something_on_alpha_mb (nice to see those impressively long comments on a "do { } while (0)" in some of the other arches ;) (Well, frv says "barrier()" for it - does it actually need that?) Yes, that's not bad at all; though in that case, I am surprised it's enough to patch up the issue. > So it boils down to smp_wmb's when setting > which is not that expensive. Yes, I wasn't worried about the much less common and anyway heavier write (allocate) path, I don't begrudge the smp_wmb's there. Thanks for calming me down! Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html