lkml.org 
[lkml]   [2003]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Nick's scheduler policy v10


Martin J. Bligh wrote:

>>This is quite a big change from v8. Fixes a few bugs in child priority,
>>and adds a small lower bound on the amount of history that is kept. This
>>should improve "fork something" times hopefully, and stops new children
>>being able to fluctuate priority so wildly.
>>
>>Eliminates "timeslice backboost" and only uses "priority backboost". This
>>decreases scheduling latency quite nicely - I can only measure 130ms for
>>a very low priority task, with a make -j3 and wildly moving an xterm around
>>in front of a mozilla window.
>>
>>Makes a fairly fundamental change to how sleeping/running is accounted.
>>It now takes into account time on the runqueue. This hopefully will keep
>>priorities more stable under varying loads.
>>
>>Includes an upper bound on the amount of priority a task can get in one
>>sleep. Hopefully this catches freak long sleeps like a SIGSTOP or unexpected
>>swaps. This change breaks the priority calculation a little bit. I'm thinking
>>about how to fix it.
>>
>>Feedback welcome! Its against 0-test4, as usual.
>>
>
>Oooh - much better.
>
>Kernbench: (make -j vmlinux, maximal tasks)
> Elapsed System User CPU
> 2.6.0-test4 45.87 116.92 571.10 1499.00
> 2.6.0-test4-nick 49.37 131.31 611.15 1500.75
> 2.6.0-test4-nick7a 49.48 125.95 617.71 1502.00
> 2.6.0-test4-nick10 46.91 114.03 584.16 1489.25
>
>SDET 128 (see disclaimer)
> Throughput Std. Dev
> 2.6.0-test4 100.0% 0.3%
> 2.6.0-test4-nick 102.9% 0.3%
> 2.6.0-test4-nick7a 105.1% 0.5%
> 2.6.0-test4-nick10 107.7% 0.2%
>

Nice.

>
>System time of kernbench is back to what it would be with virgin, or
>actually a little less. Elapsed time is still up a little bit, along
>with user time, but it's getting pretty close.
>
>Have you looked at Rick Lindsley's schedstat patches? I don't have a
>totally up-to-date version, but that might give us a better idea of
>what's going on wrt migrations, balancing, etc.
>

I haven't had a look, no. I will see.

>
>I'll try to get together a broader set of benchmarks and hammer on this
>some more ...
>
>

That would be cool. It seems to be rapidly becoming "acceptable" to
desktop users, so high end tuning needs to be next. But hopefully I
might not have to do much.


-
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: 2005-03-22 13:48    [W:0.282 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site