Re: [PATCH] Nick's scheduler policy v10

[bill davidsen]

In article <3F5044DC.10305@xxxxxxxxxxxxxxx>,
Nick Piggin  <piggin@xxxxxxxxxxxxxxx> 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.

I've been running it for a while on a dog-slow machine, 350MHz
Pentium-II with 96MB RAM, I was running V7, and I'm not sure it's an
improvement, at least on this system. while I'm doing things like a
kernel build (no -j on this box!) it feels perhaps a bit less smooth
than v7, and I do see some occasional artifact on the screen which I
didn't see with v7.

I'll be switching back and forth for a bit, and I have no working sound,
2.6.0-test4 just doesn't like the old Soundblaster, which works with
Redhat 2.4.18 whatever from RH 7.3 install. I'm trying to get a clean
oops to report when loading the aha152x module, and I want to generate
it without *any* patches, in case someone ever cares. Other than that I
do my security stuff on it, since the crypto loopback is working for me.

The v10 is better than stock test4, but I do think v7 was better. I'll
tune a few things (suggestions?) but memory isn't a big problem under my
light usage.

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/