[lkml]   [2009]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: BFS vs. mainline scheduler benchmarks and measurements
    On Sun, Sep 06 2009, Ingo Molnar wrote:
    > So ... to get to the numbers - i've tested both BFS and the tip of
    > the latest upstream scheduler tree on a testbox of mine. I
    > intentionally didnt test BFS on any really large box - because you
    > described its upper limit like this in the announcement:

    I ran a simple test as well, since I was curious to see how it performed
    wrt interactiveness. One of my pet peeves with the current scheduler is
    that I have to nice compile jobs, or my X experience is just awful while
    the compile is running.

    Now, this test case is something that attempts to see what
    interactiveness would be like. It'll run a given command line while at
    the same time logging delays. The delays are measured as follows:

    - The app creates a pipe, and forks a child that blocks on reading from
    that pipe.
    - The app sleeps for a random period of time, anywhere between 100ms
    and 2s. When it wakes up, it gets the current time and writes that to
    the pipe.
    - The child then gets woken, checks the time on its own, and logs the
    difference between the two.

    The idea here being that the delay between writing to the pipe and the
    child reading the data and comparing should (in some way) be indicative
    of how responsive the system would seem to a user.

    The test app was quickly hacked up, so don't put too much into it. The
    test run is a simple kernel compile, using -jX where X is the number of
    threads in the system. The files are cache hot, so little IO is done.
    The -x2 run is using the double number of processes as we have threads,
    eg -j128 on a 64 thread box.

    And I have to apologize for using a large system to test this on, I
    realize it's out of the scope of BFS, but it's just easier to fire one
    of these beasts up than it is to sacrifice my notebook or desktop
    machine... So it's a 64 thread box. CFS -jX runtime is the baseline at
    100, lower number means faster and vice versa. The latency numbers are
    in msecs.

    Scheduler Runtime Max lat Avg lat Std dev
    CFS 100 951 462 267
    CFS-x2 100 983 484 308

    And unfortunately this is where it ends for now, since BFS doesn't boot
    on the two boxes I tried. It hard hangs right after disk detection. But
    the latency numbers look pretty appalling for CFQ, so it's a bit of a
    shame that I did not get to compare. I'll try again later with a newer
    revision, when available.

    Jens Axboe

     \ /
      Last update: 2009-09-07 11:53    [W:0.032 / U:0.608 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site