Messages in this thread | | | Date | Mon, 01 Sep 2003 11:44:20 +1000 | From | Nick Piggin <> | Subject | Re: [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/
| |