On Fri, Oct 12, 2007 at 11:12:13AM +0200, Jarek Poplawski wrote: > On Fri, Oct 12, 2007 at 10:42:34AM +0200, Helge Hafting wrote: > > Jarek Poplawski wrote: > > >On 04-10-2007 07:23, Nick Piggin wrote: > > > > > >>According to latest memory ordering specification documents from Intel and > > >>AMD, both manufacturers are committed to in-order loads from cacheable > > >>memory > > >>for the x86 architecture. Hence, smp_rmb() may be a simple barrier. > > >> > > >... > > > > > >Great news! > > > > > >First it looks like a really great thing that it's revealed at last. > > >But then... there is probably some confusion: did we have to use > > >ineffective code for so long? > > > > > You could have tried the optimization before, and > > gotten better performance. But if without solid knowledge that > > the optimization is _valid_, you risk having a kernel > > that performs great but suffer the occational glitch and > > therefore is unstable and crash the machine "now and then". > > This sort of thing can't really be figured out by experimentation, because > > the bad cases might happen only with some processors, some > > combinations of memory/chipsets, or with some minimum > > number of processors. Such problems can be very hard > > to find, especially considering that other plain bugs also > > cause crashes. > > > > Therefore, the "ineffective code" was used because it was > > the only safe alternative. Now we know, so now we may optimize. > > Sorry, I don't understand this logic at all. Since bad cases > happen independently from any specifications and Intel doesn't > take any legal responsibility for such information, it seems we > should better still not optimize?
We already do in probably more critical and lible to be problematic cases (notably, spin_unlock). So unless there is reasonable information for us to believe this will be a problem, IMO the best thing to do is stick with the specs. Intel is pretty reasonable with documenting errata I think. With memory barriers specifically, I'm sure we have many more bugs in the kernel than AMD or Intel have in their chips ;) - 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/
