[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 09/07/2009 12:49 PM, Jens Axboe wrote:
    > 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.

    I think the problem is that CFS is optimizing for the wrong thing. It's
    trying to be fair to tasks, but these are meaningless building blocks of
    jobs, which is what the user sees and measures. Your make -j128
    dominates your interactive task by two orders of magnitude. If the
    scheduler attempts to bridge this gap using heuristics, it will fail
    badly when it misdetects since it will starve the really important
    100-thread job for a task that was misdetected as interactive.

    I think that bash (and the GUI shell) should put any new job (for bash,
    a pipeline; for the GUI, an application launch from the menu) in a
    scheduling group of its own. This way it will have equal weight in the
    scheduler's eyes with interactive tasks; one will not dominate the
    other. Of course if the cpu is free the compile job is welcome to use
    all 128 threads.

    (similarly, different login sessions should be placed in different jobs
    to avoid a heavily multithreaded screensaver from overwhelming ed).

    Do not meddle in the internals of kernels, for they are subtle and quick to panic.

     \ /
      Last update: 2009-09-07 19:59    [W:0.031 / U:19.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site