[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.031 / U:1.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site