lkml.org 
[lkml]   [2006]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] Document Linux's memory barriers
    Date
    Christoph Lameter <clameter@engr.sgi.com> wrote:

    > You need to explain the difference between the compiler reordering and the
    > control of the compilers arrangement of loads and stores and the cpu
    > reordering of stores and loads.

    Hmmm... I would hope people looking at this doc would understand that, but
    I'll see what I can come up with.

    > Note that IA64 has a much more complete set of means to reorder stores and
    > loads. i386 and x84_64 processors can only do limited reordering. So it may
    > make sense to deal with general reordering and then explain i386 as a
    > specific limited case.

    Don't you need to use sacrifice_goat() for controlling the IA64? :-)

    Besides, I'm not sure that I need to explain that any CPU is a limited case;
    I'm primarily trying to define the basic minimal guarantees you can expect
    from using a memory barrier, and what might happen if you don't. It shouldn't
    matter which arch you're dealing with, especially if you're writing a driver.

    I tried to create arch-specific sections for describing arch-specific implicit
    barriers and the extent of the explicit memory barriers on each arch, but the
    i386 section was generating lots of exceptions that it looked infeasible to
    describe them; besides, you aren't allowed to rely on such features outside of
    arch code (I count arch-specific drivers as "arch code" for this).

    > See the "Intel Itanium Architecture Software Developer's Manual"
    > (available from intels website). Look at Volume 1 section 2.6
    > "Speculation" and 4.4 "Memory Access"

    I've added that to the refs, thanks.

    > Also the specific barrier functions of various locking elements varies to
    > some extend.

    Please elaborate.

    David
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-08 18:37    [W:0.020 / U:35.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site