[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.037 / U:39.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site