Messages in this thread | | | Date | Tue, 19 Aug 2003 20:49:24 +0200 | From | Mike Galbraith <> | Subject | Re: [CFT][PATCH] new scheduler policy |
| |
At 11:40 PM 8/19/2003 +1000, Nick Piggin wrote:
>Mike Galbraith wrote: > >>At 11:53 AM 8/19/2003 +1000, Nick Piggin wrote: >> >>>Hi everyone, >>> >>>As per the latest trend these days, I've done some tinkering with >>>the cpu scheduler. I have gone in the opposite direction of most >>>of the recent stuff and come out with something that can be nearly >>>as good interactivity wise (for me). >>> >>>I haven't run many tests on it - my mind blanked when I tried to >>>remember the scores of scheduler "exploits" thrown around. So if >>>anyone would like to suggest some, or better still, run some, >>>please do so. And be nice, this isn't my type of scheduler :P >> >> >>Ok, I took it out for a quick spin... > > >Thanks again. > >> >>Test-starve.c starvation is back (curable via other means), but irman2 is >>utterly harmless. Responsiveness under load is very nice until I get to >>the "very hefty" end of the spectrum (expected). Throughput is down a >>bit at make -j30, and there are many cc1's running at very high priority >>once swap becomes moderately busy. OTOH, concurrency for the make -jN in >>general appears to be up a bit. X is pretty choppy when moving windows >>around, but that _appears_ to be the newer/tamer backboost bleeding a >>kdeinit thread a bit too dry. (I think it'll be easy to correct, will >>let you know if what I have in mind to test that theory works >>out). Ending on a decidedly positive note, I can no longer reproduce >>priority inversion troubles with xmms's gl thread, nor with blender. > > >Well, it sounds like a good start, though I'll have to get up to scratch >on the array of scheduler badness programs!
(looks like a fine start to me. my box [and subjective driver] give it a one thumb up plus change;)
>I expect throughput to be down in this release due to the timeslice thing. >This should be fixable. > >I think either there is a bug in my accounting somewhere or I have not quite >thought it though properly because priorities don't seem to get distributed >well. Also its not using the nanosecond timing stuff (yet). This might help >a bit.
Hmm. I watched priority distribution (eyeballs, not instrumentation), and it looked "right" to me until the load reached "fairly hefty"... at the point where swap really became a factor, distribution flattened, and the mean priority rose (high). I did see some odd-ball high priority cc1's at the low to moderate end (historically indicator of trouble here), but not much. At what I call moderate load, it behaved well, and looked/felt good.
-Mike
- 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/
| |