lkml.org 
[lkml]   [2009]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 3/3] slub: sort parital list when thrashing
    On Mon, 30 Mar 2009, Christoph Lameter wrote:

    > > @@ -1720,6 +1727,15 @@ checks_ok:
    > > if (unlikely(!prior)) {
    > > add_partial(get_node(s, page_to_nid(page)), page, 1);
    > > stat(c, FREE_ADD_PARTIAL);
    > > + } else if (c->slowpath_allocs >= SLAB_THRASHING_THRESHOLD) {
    > > + /*
    > > + * If the cache is actively slab thrashing, it's necessary to
    > > + * move partial slabs to the head of the list so there isn't
    > > + * excessive partial list scanning while holding list_lock.
    > > + */
    > > + if (!skip_partial(s, page))
    > > + move_partial_to_head(get_node(s, page_to_nid(page)),
    > > + page);
    > > }
    > >
    > > out_unlock:
    > >
    >
    > This again adds code to a pretty hot path.
    >
    > What is the impact of the additional hot path code?
    >

    I'll be collecting more data now that there's a general desire for a
    default slab_thrash_ratio value, so we'll implicitly see the performance
    degradation for non-thrashing slab caches. Mel had suggested a couple of
    benchmarks to try and my hypothesis is that they won't regress with a
    default ratio of 20 for all caches with >= 20 objects per slab (at least a
    4 object threshold for determining thrash).


    \
     
     \ /
      Last update: 2009-03-30 22:33    [W:0.022 / U:29.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site