[lkml]   [2006]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Document Linux's memory barriers [try #2]
    On Wed, Mar 08, 2006 at 05:04:51PM +0000, David Howells wrote:
    > > [For information on bus mastering DMA and coherency please read ....]
    > > sincee have a doc on this
    > Documentation/pci.txt?


    > > The use of volatile generates poorer code and hides the serialization in
    > > type declarations that may be far from the code.
    > I'm not sure what you mean by that.

    in foo.h

    struct blah {
    volatile int x; /* need serialization

    2 million miles away

    blah.x = 1;
    blah.y = 4;

    And you've no idea that its magically serialized due to a type declaration
    in a header you've never read. Hence the "dont use volatile" rule

    > > Is this true of IA-64 ??
    > Are you referring to non-temporal loads and stores?

    Yep. But Matthew answered that

    > > Should clarify local ordering v SMP ordering for locks implied here.
    > Do you mean explain what each sort of lock does?

    spin_unlock ensures that local CPU writes before the lock are visible
    to all processors before the lock is dropped but it has no effect on
    I/O ordering. Just a need for clarity.

    > > > + (*) inX(), outX():
    > > > +
    > > > + These are intended to talk to legacy i386 hardware using an alternate bus
    > > > + addressing mode. They are synchronous as far as the x86 CPUs are
    > >
    > > Not really true. Lots of PCI devices use them. Need to talk about "I/O space"
    > Which bit is not really true?

    The "legacy i386 hardware" bit. Many processors have an I/O space.

    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: 2006-03-08 18:38    [W:0.025 / U:2.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site