lkml.org 
[lkml]   [2011]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[slubllv3 00/21] SLUB: Lockless freelists for objects V3
    V2->V3
    - Provide statistics
    - Fallback logic to page lock if cmpxchg16b is not available.
    - Better counter support
    - More cleanups and clarifications

    Well here is another result of my obsession with SLAB allocators. There must be
    some way to get an allocator done that is faster without queueing and I hope
    that we are now there (maybe only almost...).

    This patchset implement wider lockless operations in slub affecting most of the
    slowpaths. In particular the patch decreases the overhead in the performance
    critical section of __slab_free.

    One test that I ran was "hackbench 200 process 200" on 2.6.29-rc3 under KVM

    Run SLAB SLUB SLUB LL
    1st 35.2 35.9 31.9
    2nd 34.6 30.8 27.9
    3rd 33.8 29.9 28.8

    Note that the SLUB version in 2.6.29-rc1 already has an optimized allocation
    and free path using this_cpu_cmpxchg_double(). SLUB LL takes it to new heights
    by also using cmpxchg_double() in the slowpaths (especially in the kfree()
    case where we cannot queue).

    The patch uses a cmpxchg_double (also introduced here) to do an atomic change
    on the state of a slab page that includes the following pieces of information:

    1. Freelist pointer
    2. Number of objects inuse
    3. Frozen state of a slab

    Disabling of interrupts (which is a significant latency in the
    allocator paths) is avoided in the __slab_free case.

    There are some concerns with this patch. The use of cmpxchg_double on
    fields of the page struct requires alignment of the fields to double
    word boundaries. That can only be accomplished by adding some padding
    to struct page which blows it up to 64 byte (on x86_64). Comments
    in the source describe these things in more detail.

    The cmpxchg_double() operation introduced here could also be used to
    update other doublewords in the page struct in a lockless fashion. One
    can envision page state changes that involved flags and mappings or
    maybe do list operations locklessly (but with the current scheme we
    would need to update two other words elsewhere at the same time too,
    so another scheme would be needed).



    \
     
     \ /
      Last update: 2011-04-15 22:53    [W:4.497 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site