lkml.org 
[lkml]   [2009]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] lib: Provide generic atomic64_t implementation
    On Sun, Jun 14, 2009 at 04:04:36PM +0300, Avi Kivity wrote:
    > Paul Mackerras wrote:
    >> Avi Kivity writes:
    >>
    >>
    >>> An alternative implementation using 64-bit cmpxchg will recover most
    >>> of the costs of hashed spinlocks. I assume most serious 32-bit
    >>> architectures have them?
    >>>
    >>
    >> Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
    >> it already has an atomic64_t implementation using cmpxchg8b (or
    >> whatever it's called).
    >>
    >
    > Yes (and it is cmpxchg8b). I'm surprised powerpc doesn't have DCAS support.

    Well, s390 and m68k have the equivalent (although I don't think Linux
    suppiorts SMP m68k, although some dual 68040/68060 boards have existed).

    But 32 bit PPC will never have it. It just does not fit in the architecture
    since integer loads and stores are limited to 32 bit (or split into 32 bit
    chunks). Besides that there is no instruction that performs a read-modify-write
    of memory. This would make the LSU much more complex for a corner case.

    Hey, Intel also botched the first implementation of cmpxchg8b on the Pentium:
    the (in)famous f00f bug is actually "lock cmpxchg8b" with a register operand.

    Now for these counters, other solutions could be considered, like using
    the most significant bit as a lock and having "only" 63 usable bits (when
    counting ns, this overflows at 292 years).

    >
    >> My thinking is that the 32-bit non-x86 architectures will be mostly
    >> UP, so the overhead is just an interrupt enable/restore. Those that
    >> are SMP I would expect to be small SMP -- mostly just 2 cpus and maybe
    >> a few 4-way systems.
    >>
    >
    > The new Nehalems provide 8 logical threads in a single socket. All
    > those threads share a cache, and they have cmpxchg8b anyway, so this
    > won't matter.
    >

    The problem is not Nehalem (who wants to run 32 bit kernels on a Nehalem
    anyway) or x86.

    The problem is that the assumption that the largest PPC32 SMP are 4 way
    may be outdated:

    http://www.freescale.com/webapp/sps/site/prod_summary.jsp?fastpreview=1&code=P4080

    and some products including that processor have been announced (I don't know
    whether they are shipping or not) and (apparently) run Linux.

    Gabriel


    \
     
     \ /
      Last update: 2009-06-17 00:49    [W:0.025 / U:0.528 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site