lkml.org 
[lkml]   [2007]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Major regression on hackbench with SLUB

    [ Note: I'm currently having problems with my email:
    http://www.domaindirect.com/network.html
    I'm in the process of setting up my own personal email server. ]


    > > Can you do one run with oprofile, and see exactly where the cost is? It
    > > should hopefully be pretty darn obvious, considering your timing.

    I kicked off my kernel tests which will take a few hours.
    I run "make -j256" (4*nr_CPUS) 10 times at SCHED_OTHER and 10 times
    at SCHED_FIFO (chrt -f 10) for both SLUB and SLAB.

    This is automated, so I need to wait for it to finish before I can
    continue other tests.

    > The biggest cost of __slab_alloc() in my profile is the "slab_lock()", but
    > that may not be the one that causes problems in a 64-cpu setup, so it
    > would be good to have that verified.

    I'll run oprofile as soon as the kernel build test is done.

    > case which can trigger on NUMA. That's another potential explanation of
    > why you'd see such a *huge* slowdown (ie if the whole node-match thing
    > doesn't work out, slub just never gets the fast-case at all). That said,
    > the number of places that actually pass a specific node to slub is very
    > limited, so I suspect it's not the node matching. But just disabling that
    > test in slab_alloc() might be one thing to test.

    I'll try that after the oprofile.

    Thanks,

    -- Steve



    \
     
     \ /
      Last update: 2007-12-07 20:03    [W:4.761 / U:0.728 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site