lkml.org 
[lkml]   [2011]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/3] slub: set a criteria for slub node partial adding
    On Wed, 7 Dec 2011, Shaohua Li wrote:

    > interesting. I did similar experiment before (try to sort the page
    > according to free number), but it appears quite hard. The free number of
    > a page is dynamic, eg more slabs can be freed when the page is in
    > partial list. And in netperf test, the partial list could be very very
    > long. Can you post your patch, I definitely what to look at it.

    It was over a couple of years ago and the slub code has changed
    significantly since then, but you can see the general concept of the "slab
    thrashing" problem with netperf and my solution back then:

    http://marc.info/?l=linux-kernel&m=123839191416478
    http://marc.info/?l=linux-kernel&m=123839203016592
    http://marc.info/?l=linux-kernel&m=123839202916583

    I also had a separate patchset that, instead of this approach, would just
    iterate through the partial list in get_partial_node() looking for
    anything where the number of free objects met a certain threshold, which
    still defaulted to 25% and instantly picked it. The overhead was taking
    slab_lock() for each page, but that was nullified by the performance
    speedup of using the alloc fastpath a majority of the time for both
    kmalloc-256 and kmalloc-2k when in the past it had only been able to serve
    one or two allocs. If no partial slab met the threshold, the slab_lock()
    is held of the partial slab with the most free objects and returned
    instead.

    > What I have about the partial list is it wastes a lot of memory.

    That's not going to be helped with the above approach since we typically
    try to fill a partial slab with many free objects, but it also won't be
    severely impacted because if the threshold is kept small enough, then we
    simply return the first partial slab that meets the criteria. That allows
    the partial slabs at the end of the list to hopefully become mostly free.

    And, for completeness, there's also a possibility that you have some
    completely free slabs on the partial list that coule be freed back to the
    buddy allocator by decreasing min_partial by way of
    /sys/kernel/slab/cache/min_partial at the risk of performance and then
    invoke /sys/kernel/slab/cache/shrink to free the unused slabs.


    \
     
     \ /
      Last update: 2011-12-07 08:31    [W:3.633 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site