[lkml]   [2007]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [rfc][patch 3/3] x86: optimise barriers
On Fri, Oct 12, 2007 at 08:13:52AM -0700, Linus Torvalds wrote:
> On Fri, 12 Oct 2007, Jarek Poplawski wrote:
> So no, there's no way a software person could have afforded to say "it
> seems to work on my setup even without the barrier". On a dual-socket
> setup with s shared bus, that says absolutely *nothing* about the
> behaviour of the exact same CPU when used with a multi-bus chipset. Not to
> mention another revisions of the same CPU - much less a whole other
> microarchitecture.

Yes, I still can't believe this, but after some more reading I start
to admit such things can happen in computer "science" too... I've
mentioned a lost performance, but as a matter of fact I've been more
concerned with the problem of truth:

From: Intel(R) 64 and IA-32 Architectures Software Developer's Manual
Volume 3A:

"7.2.2 Memory Ordering in P6 and More Recent Processor Families
1. Reads can be carried out speculatively and in any order.

So, it looks to me like almost the 1-st Commandment. Some people (like
me) did believe this, others tried to check, and it was respected for
years notwithstanding nobody had ever seen such an event.

And then, a few years later, we have this:

From: Intel(R) 64 Architecture Memory Ordering White Paper

"2 Memory ordering for write-back (WB) memory
Intel 64 memory ordering obeys the following principles:
1. Loads are not reordered with other loads.

I know, technically this doesn't have to be a contradiction (for not
WB), but to me it's something like: "OK, Elvis lives and this guy is
not real Paul McCartney too" in an official CIA statement!

> Also, please note that we didn't even just change the barriers immediately
> when the docs came out. I want to do it soon - still *early* in the 2.6.24
> development cycle - exactly because bugs happen, and if somebody notices
> something strange, we'll have more time to perhaps decide that "oops,
> there's something bad going on, let's undo this for the real 2.6.24
> release until we can figure out the exact pattern".

I'm still so "dazed and confused" that I can't tell this (or anything)
is right...

Thanks very much for so extensive and sound explanation,

Jarek P.

PS: Btw, I apologize Helge for not trusting her: "verification by
testing would not be trivial" words.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-10-15 09:43    [W:0.162 / U:0.632 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site