lkml.org 
[lkml]   [2006]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [SCHED] wrong priority calc - SIMPLE test case
Date
On Saturday 28 January 2006 07:06, MIke Galbraith wrote:
> What do you think of the below as an evaluation patch? It leaves the
> bits I'd really like to change (INTERACTIVE_SLEEP() for one), so it can
> be switched on and off for easy comparison and regression testing.
>
> I really didn't want to add more to the task struct, but after trying
> different things, a timeout was the most effective means of keeping the
> nice burst aspect of the interactivity logic but still make sure that a
> burst doesn't turn into starvation.
>
> The workings are dirt simple just as before. The goal is to keep
> sleep_avg and slice_avg balanced. When an imbalance starts, immediately
> cut off interactive bonus points. If the imbalance doesn't correct
> itself through normal sleep_avg usage, we'll soon hit the (1 dynamic
> prio) trigger point, which starts a countdown toward active
> intervention. The default setting is that a task can run at higher
> dynamic priority than it's cpu usage can justify for 5 seconds. After
> than, we start trying to work off the deficit, and if we don't succeeded
> within another second (ie it was a big deficit), we demote the offender
> to the rank his cpu usage indicates.
>
> The strategy works well enough to take the wind out of irman2's sails,
> and interactive tasks can still do a nice reasonable burst of activity
> without being evicted. Down side to starvation control is that X is
> sometimes a serious cpu user, and _can_ end up in the expired array (not
> nice under load). I personally don't think that's a show stopper
> though... all you have to do is tell the scheduler that what it already
> noticed, that X is a piggy, but an OK piggy by renicing it. It becomes
> immune from active throttling, and all is well. I know that's not going
> to be popular, but you just can't let X have free rein without leaving
> the barn door wide open. (maybe that switch should stay since the
> majority of boxen are workstations, and default to off?).

Sounds good but I have to disagree on the X renice thing. It's not that I have
a religious objection to renicing things. The problem is that our mainline
scheduler determines latency also by nice level. This means that if you
-renice a bursty cpu hog like X, then audio applications will fail unless
they too are reniced. Try it on your patch.

Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-28 00:21    [W:0.122 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site