On Tue, 24 Jul 2007, Nick Piggin wrote: > Satyam Sharma wrote: > > On Tue, 24 Jul 2007, Nick Piggin wrote: > > > Satyam Sharma wrote: > > > [...] > > > > So let's make these proper no-ops, because that's exactly what we > > > > require > > > > these to be on the i386 platform. > > > > > > No. clear_bit is not a compiler barrier on i386, > > > > Obvious. > > > > > thus smp_mb__before/after > > > must be.
> > Not so obvious. Why do we require these to be a full compiler barrier > > is precisely the question I raised here. > > Consider this (the above two functions exist only for clear_bit(), > > the atomic variant, as you already know), the _only_ memory reference > > we care about is that of the address of the passed bit-string: > > No. Memory barriers explicitly extend to all memory references. [ Compiler barrier, you mean, that's not true of CPU barriers. ] In any case, I know that, obviously. I asked "why" not "what" :-) i.e. why should we care about other addresses / why do we want to extend the compiler barrier to all memory references -- but Jeremy seems to have answered that ... > > (1) The compiler must not optimize / elid it (i.e. we need to disallow > > compiler optimization for that reference) -- but we've already taken > > care of that with the __asm__ __volatile__ and the constraints on > > the memory "addr" operand there, and, > > (2) For the i386, it also includes an implicit memory (CPU) barrier > > already. > > Repeating what has been said before: A CPU memory barrier is not a > compiler barrier or vice versa. Seeing as we are talking about > the compiler barrier, it is irrelevant as to whether or not the > assembly includes a CPU barrier. I think it is quite relevant, in fact. From Documentation/atomic_ops.txt, smp_mb__{before,after}_clear_bit(), as the name itself suggests, must be _CPU barriers_ for those arch's that don't have an implicit _CPU barrier_ in the clear_bit() itself [ which i386 does have already ]. As for a compiler barrier, the asm there already guarantees the compiler will not optimize references to _that_ address, but there could still be the memset()/set{clear}_bit() interspersing pitfalls for example, so yeah the memory clobber would probably protect us there. Satyam - 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/