On Fri, 17 Aug 2007, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
> >
> > The cost of doing so seems to me to be well down in the noise - 44
> > bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> > the extra few cycles for the occasional extra load would be measurable
> > (they should all hit in the L1 dcache). I don't mind if x86[-64] have
> > atomic_read/set be nonvolatile and find all the missing barriers, but
> > for now on powerpc, I think that not having to find those missing
> > barriers is worth the 0.00076% increase in kernel text size.
>
> BTW, the sort of missing barriers that triggered this thread
> aren't that subtle. It'll result in a simple lock-up if the
> loop condition holds upon entry. At which point it's fairly
> straightforward to find the culprit.
Not necessarily. A barrier-less buggy code such as below:
atomic_set(&v, 0);
... /* some initial code */
while (atomic_read(&v))
;
... /* code that MUST NOT be executed unless v becomes non-zero */
(where v->counter is has no volatile access semantics)
could be generated by the compiler to simply *elid* or *do away* with
the loop itself, thereby making the:
"/* code that MUST NOT be executed unless v becomes non-zero */"
to be executed even when v is zero! That is subtle indeed, and causes
no hard lockups.
Granted, the above IS buggy code. But, the stated objective is to avoid
heisenbugs. And we have driver / subsystem maintainers such as Stefan
coming up and admitting that often a lot of code that's written to use
atomic_read() does assume the read will not be elided by the compiler.
See, I agree, "volatility" semantics != what we often want. However, if
what we want is compiler barrier, for only the object under consideration,
"volatility" semantics aren't really "nonsensical" or anything.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
