[lkml]   [2003]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.5.65-mm2
    At 06:04 PM 3/19/2003 -0500, Robert Love wrote:
    >On Wed, 2003-03-19 at 17:51, Steven P. Cole wrote:
    > > I'll try the different value of max_timeslice with dbench on
    > > reiserfs next. That's where the lack of response was most evident.
    >I am curious as to whether reverting sched-D4 fixes this.
    >If not, the first step is seeing whether this is a bad decision made by
    >the interactivity estimator. Something like:
    > ps -eo pid,nice,priority,command
    >for dbench, evolution, and X might be useful.

    I think I know what he'll see... elevated priority tasks doing round
    robin. Watch with top d1 showing only runnable tasks and you can see the

    The problem as I see it is that when you have a number of tasks which
    become elevated to interactive status, they'll round robin and starve
    non-interactive tasks basically forever. This is also why my make -j30
    bzImage introduces concurrency problems. Despite gcc being a cpu hog, when
    enough of them are running, those which have to wait for more time than
    they consume via cpu usage eventually achieve elevated status and round
    robin until they exit... throttling concurrency. Limiting the amount of
    boost that a task can gain via one activation helps this problem
    considerably, but does not eliminate it.

    (think what happens to EXPIRED_STARVING when you have 30 hogs running, a
    few of them doing round robin, and the rest of them just _waiting_ for that
    queue switch to happen. :-/ ATM, I'm also gathering sleep time at
    schedule time [friendly tasks gain], so sleep_avg will never be consumed if
    you have more than one hog running. I made the starvation problem better
    for some loads, but utterly deadly for others.)

    Something I'm going to try today (yesterday was educational if not
    wonderfully fruitful) is to limit the amount of time a piggy task can
    remain active in the hope of reducing the time interactive hogs can starve
    their expired brethren. I'm currently thinking forced expire after some
    number of switches * cpu_usage is reached might cure the starvation without
    destroying sleep_avg.

    Suggestions very welcome. (fun problem:)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:34    [W:0.021 / U:67.008 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site