Re: page table lock patch V15 [0/7]: overview

From: Christoph Lameter (clameter_at_sgi.com)
Date: 01/14/05

  • Next message: Erez Zadok: "Re: [RFC] shared subtrees" 
    Date:	Thu, 13 Jan 2005 17:09:04 -0800 (PST)
To: Andi Kleen <ak@muc.de>

    On Thu, 13 Jan 2005, Andi Kleen wrote:

    > On Thu, Jan 13, 2005 at 09:11:29AM -0800, Christoph Lameter wrote:
    > > On Wed, 13 Jan 2005, Andi Kleen wrote:
    > >
    > > > Alternatively you can use a lazy load, checking for changes.
    > > > (untested)
    > > >
    > > > pte_t read_pte(volatile pte_t *pte)
    > > > {
    > > > pte_t n;
    > > > do {
    > > > n.pte_low = pte->pte_low;
    > > > rmb();
    > > > n.pte_high = pte->pte_high;
    > > > rmb();
    > > > } while (n.pte_low != pte->pte_low);
    > > > return pte;

    I think this is not necessary. Most IA32 processors do 64
    bit operations in an atomic way in the same way as IA64. We can cut out
    all the stuff we put in to simulate 64 bit atomicity for i386 PAE mode if
    we just use convince the compiler to use 64 bit fetches and stores. 486
    cpus and earlier are the only ones unable to do 64 bit atomic ops but
    those wont be able to use PAE mode anyhow.

    Page 231 of Volume 3 of the Intel IA32 manual states regarding atomicity
    of operations:

    7.1.1. Guaranteed Atomic Operations

    The Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors
    guarantee that the following basic memory operations will always be
    carried out atomically:

    o reading or writing a byte
    o reading or writing a word aligned on a 16-bit boundary
    o reading or writing a doubleword aligned on a 32-bit boundary

    The Pentium 4, Intel Xeon, and P6 family, and Pentium processors guarantee
    that the following additional memory operations will always be carried out
    atomically:

    o reading or writing a quadword aligned on a 64-bit boundary
    o 16-bit accesses to uncached memory locations that fit within a 32-bit data bus
    o The P6 family processors guarantee that the following additional memory
    operation will always be carried out atomically:
    o unaligned 16-, 32-, and 64-bit accesses to cached memory that fit
    within a 32-byte cache

    .... off to look for 64bit store and load instructions in the intel
    manuals. I feel much better about keeping the existing approach.
    -
    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/

  • Next message: Erez Zadok: "Re: [RFC] shared subtrees"

    Relevant Pages

    • Re: Lock variables between two threads
      ... L2/L3 cache shared between cores), or always an entire word (or ... atomicity of the read/modify/write to the cache line even with ... Reading or writing a byte. ...
      (microsoft.public.vc.language)
    • What does atomic_read actually do?
      ... It doesn't do anything that would actually guarantee that the fetch from ... memory would be atomic as far as I can see, at least in the x86 version. ... The C standard has nothing to say about atomicity w.r.t. multithreading or ...
      (Linux-Kernel)
    • Re: What does atomic_read actually do?
      ... > from memory would be atomic as far as I can see, at least in the x86 ... The C standard has nothing to say about atomicity w.r.t. ...
      (Linux-Kernel)
    • Re: CAS timings
      ... >>truction work on cacheable memory only. ... cache line of a specific memory location in its cache. ... This is true for both the simple store instruction as well as the ... > and atomicity of memory operations between processors ...
      (comp.unix.solaris)
    • Re: [PATCH 6/8] i386: bitops: Dont mark memory as clobbered unnecessarily
      ... for the atomic versions we don't care if we're asking gcc to ... It has nothing to do with atomicity and all to do with ordering. ... The memory clobber, or the volatile asm? ...
      (Linux-Kernel)
    Loading