[lkml]   [2002]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
Hash: SHA1

>Robert Love wrote:
>> ...
>> Not too sure what to make of it. It shows the interactivity estimator
>> does indeed help... but only if what you consider "important" is what is
>> considered "interactive" by the estimator. Andrew will say that is too
>> often not the case.
>That is too often not the case.
>I can get the desktop machine working about as comfortably
>as 2.4.19 with:
># echo 10 > max_timeslice
># echo 0 > prio_bonus_ratio
>ie: disabling all the fancy new scheduler features :(
>Dropping max_timeslice fixes the enormous stalls which happen
>when an interactive process gets incorrectly identified as a
>cpu hog. (OK, that's expected)
>But when switching virtual desktops some windows still take a
>large fraction of a second to redraw themselves. Disabling the
>interactivity estimator fixes that up too. (Not OK. That's bad)
>hm. It's actually quite nice. I'd be prepared to throw away
>a few cycles for this.
>I don't expect the interactivity/cpuhog estimator will ever work
>properly on the desktop, frankly. There will always be failure
>cases when a sudden swing in load causes it to make the wrong
>So it appears that to stem my stream of complaints we need to
>merge scheduler_tunables.patch and edit my /etc/rc.local.

I guess this explains why my variable timeslice thingy in -ck helps on the
desktop. Basically by shortening the timeslice it is masking the effect of
the interactivity estimator under load. That is, it is treating the symptoms
of having an interactivity estimator rather than tackling the cause.

Version: GnuPG v1.2.0 (GNU/Linux)
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:31    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean