Messages in this thread | | | Date | Tue, 26 Aug 2003 14:04:38 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] Nick's scheduler policy v7 |
| |
Martin J. Bligh wrote:
>>I didn't miss 5 revisions, I'll just stick to using my internal >>numbering for releases. >> >>This one has a few changes. Children now get a priority boost >>on fork, and parents retain more priority after forking a child, >>however exiting CPU hogs will now penalise parents a bit. >> >>Timeslice scaling was tweaked a bit. Oh and remember raising X's >>priority should _help_ interactivity with this patch, and IMO is >>not an unreasonable thing to be doing. >> >>Please test. I'm not getting enough feedback! >> > >Well, it's actually a bit faster than either mainline or your previous >rev whilst running SDET: > >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% > >But kernbench is significantly slower. The increase in sys time has >dropped from last time, but user time is up. > >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 >
Thanks Martin. OK, so the drop in kernbench is quite likely to be what I thought - elevated priorities (caused by eg. make waiting for children) causing timeslices to shrink. As long as its not a fundamental problem, this should be able to be tweaked back.
Yeah, I guess the random kernel and user times are probably due to cache.
- 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/
| |