Messages in this thread | | | Date | Tue, 30 Sep 2003 11:12:06 +1000 | From | Nick Piggin <> | Subject | Re: Linux 2.6.0-test6 |
| |
bill davidsen wrote:
>In article <3F77BB2C.7030402@cyberone.com.au>, >Nick Piggin <piggin@cyberone.com.au> wrote: > >| AFAIK, Con's scheduler doesn't change the nice implementation at all. >| Possibly some of his changes amplify its problems, or, more likely they >| remove most other scheduler problems leaving this one noticable. >| >| If X is running at -20, and xmms at +19, xmms is supposed to still get >| 5% of the CPU. Should be enough to run fine. Unfortunately this is >| achieved by giving X very large timeslices, so xmms's scheduling latency >| becomes large. The interactivity bonuses don't help, either. > >Clearly the "some is good, more is better" approach doesn't provide >stable balance between sound and cpu hogs. It isn't a question of "how >much" cpu, just "when"which works or not. > >This is sort of like the deadline scheduler in that it trades of >throughput for avoiding jackpot cases. I think that's desired behaviour >in a CPU schedular too, at least if used by humans. >
I'm not sure what you mean. There is nothing good to say about Ingo's nice mechanism though (sorry Ingo, its otherwise a very nice scheduler!).
In my scheduler, nice -20 processes get small timeslices so scheduling latency stays low or even gets lower, while nice +19 ones get large timeslices for lower context switches and better cache efficiency. As you would like.
- 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/
| |