lkml.org 
[lkml]   [2005]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] SMP alternatives


    On Wed, 23 Nov 2005, Alan Cox wrote:

    > On Mer, 2005-11-23 at 10:42 -0800, Linus Torvalds wrote:
    >> Of course, if it's in one of the low 12 bits of %cr3, there would have to
    >> be a "enable this bit" in %cr4 or something. Historically, you could write
    >> any crap in the low bits, I think.
    >
    > There is a much much better way to do it than just user space and
    > without hitting cr3/cr4 - put "lock works" in the PAT and while we'll
    > have to add PAT support which we need to do anyway we would get a world
    > where on uniprocessor lock prefix only works on addresse targets we want
    > it to - ie pci_alloc_consistent() pages.

    Given the CPU architecture it is unimplementable. Intructions are split
    into microinstuctions and they are executed out of order. PAT is looked up
    when LOAD microinstruction is executed. Imagine this

    MOV EDX, [address1]
    LOCK ADD [address2], EDX

    that is translated to

    LOAD EDX, [address1]
    LOAD TMP1, [address2]
    ADD TMP1, EDX
    STORE [address2], TMP1

    ... now LOAD finds LOCK attribute in PAT --- so it locks the bus, however
    EDX is still not loaded. Now LOAD EDX can't execute because the bus is
    locked and ADD and STORE can't execute because they're waiting for LOAD
    EDX. Deadlock.

    Locks are so slow not because they are locks (if the target is in L1
    cache, they operate only on cache and don't go to bus at all), but because
    they need to flush completely microinstruction pool to avoid problems like
    this. Of course Intel won't waste silicon in the execution engine for
    instructions that execute so rarely, so they microcode them instead. So
    lock detection is done at the decoder.

    Mikulas

    > Alan
    >
    > -
    > 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/
    >
    -
    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-11-24 04:26    [W:0.049 / U:150.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site