lkml.org 
[lkml]   [2003]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [CFT][RFC] HT scheduler
    On Tue, 16 Dec 2003, Linus Torvalds wrote:

    > On Tue, 16 Dec 2003, Davide Libenzi wrote:
    > > > I bet it is. In a big way.
    > > >
    > > > The lock does two independent things:
    > > > - it tells the core that it can't just crack up the load and store.
    > > > - it also tells other memory ops that they can't re-order around it.
    > >
    > > You forgot the one where no HT knowledge can be used for optimizations.
    > >
    > > - Asserting the CPU's #LOCK pin to take control of the system bus. That in
    > > MP system translate into the signaling CPU taking full control of the
    > > system bus until the pin is deasserted.
    >
    > I think this is historical and no longer true.
    >
    > All modern CPU's do atomic accesses on a cache coherency (and write buffer
    > ordering) level, and it has nothing to do with the external bus any more.
    >
    > I suspect locked accesses to memory-mapped IO _may_ still set an external
    > flag, but I seriously doubt anybody cares. I wouldn't be surprised if the
    > pin doesn't even exist any more.

    I just checked the P6 stuff. It does exist but it can is some cases
    (write-back access on data completely on cache, for example) be caught by
    the cache controller that handles the following ops using normal cache
    coherency mechanisms.



    - Davide


    -
    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: 2005-03-22 13:59    [W:0.021 / U:0.320 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site