[lkml]   [1999]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: spin_unlock optimization(i386)

    On Fri, 26 Nov 1999, Linus Torvalds wrote:

    > On x86 where x >=6, the MTRR's do the same job. That's why the MTRR's were
    > introduced: because the P6 core can re-order accesses, you can no longer
    > afford to wait until the access hits the bus to know whether it is RAM or
    > not, so you have to introduce a in-core data structure to maintain that
    > knowledge.

    i believe this still doesnt turn off store forwarding. If two PCI commands
    are written to the same register then they might get 'merged', resulting
    in the first written command to be lost. This usually doesnt happen, but
    can happen, and does happen in some cases.

    > So note that we do NOT want to make all ioremapped accesses
    > uncacheable, because then we could no longer do clever tricks with
    > MTRR's.

    the only MTRR stuff we do right now is mmap()-ing the frame buffer via
    /dev/mem, right? In that case we are doing things outside of ioremap()'s
    scope anyway.

    > And we know that we want to do MTRR stuff, at least eventually.

    yep, i agree that we want to do WC in drivers/video/*.c, but i think the
    interface should be additive. We still have __ioremap(,,flags), and can
    add an ioremap_wc() function easily, no? What i mean is that right now 99%
    of ioremap()s is for ordinary shared PCI memory drivers, which use command
    registers, and for those anything non-UC is potentially lethal.

    actually this is how ioremap_nocache() popped up, i just didnt understand
    this issue at that time. (i hope i do now :). About 2 years ago CISCO
    found out when developing drivers that their driver fails mysteriously on
    PPro boxes. So i sent a small patch to add ioremap_nocache(), but that's
    the wrong solution now i believe.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.047 / U:9.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site