[lkml]   [2009]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] SLQB slab allocator (try 2)
    On Mon, Feb 16, 2009 at 09:17:58PM +0200, Pekka Enberg wrote:
    > Hi Mel,
    > Mel Gorman wrote:
    >> I haven't done much digging in here yet. Between the large page bug and
    >> other patches in my inbox, I haven't had the chance yet but that doesn't
    >> stop anyone else taking a look.
    > So how big does an improvement/regression have to be not to be
    > considered within noise? I mean, I randomly picked one of the results
    > ("x86-64 speccpu integer tests") and ran it through my "summarize"
    > script and got the following results:
    > min max mean std_dev
    > slub 0.96 1.09 1.01 0.04
    > slub-min 0.95 1.10 1.00 0.04
    > slub-rvrt 0.90 1.08 0.99 0.05
    > slqb 0.96 1.07 1.00 0.04

    Well, it doesn't make a whole pile of sense to get the average of these ratios
    or the deviation between them. Each of the tests behave very differently. I'd
    consider anything over 0.5% significant but I also have to admit I wasn't
    doing multiple runs this time due to the length of time it takes. In a
    previous test, I ran them 3 times each and didn't spot large deviations.

    > Apart from slub-rvrt (which seems to be regressing, interesting) all the
    > allocators seem to perform equally well. Hmm?

    For this stuff, they are reasonably close but I don't believe thye are
    allocator intensive either. SPEC CPU was brought up as a workload HPC people
    would care about. Bear in mind it's also not testing NUMA or CPU scalability
    really well. It's one data-point. netperf is a much more allocator intensive

    > Btw, Yanmin, do you have access to the tests Mel is running (especially
    > the ones where slub-rvrt seems to do worse)? Can you see this kind of
    > regression? The results make we wonder whether we should avoid reverting
    > all of the page allocator pass-through and just add a kmalloc cache for
    > 8K allocations. Or not address the netperf regression at all. Double-hmm.

    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab

     \ /
      Last update: 2009-02-18 12:23    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean