Re: Linux 2.6.0-test6

[Nick Piggin <piggin@cyberone.com.au>]

bill davidsen wrote:

>In article <3F78D866.5070605@cyberone.com.au>,
>Nick Piggin  <piggin@cyberone.com.au> wrote:
>| 
>| 
>| 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!).
>
>Oh, I think the test5-mm4 behaviour is far better than yours in terms of
>throughput. I would expect that it could have several percent less
>system time, leaving it for cpu-bound user processes. However, on my
>little test machine (PII-350 w/ 96MB) running patch to get a kernel
>source tree ready makes the system damn near unusable. With your v15
>patch neither patch nor a kernel build is a real problem (I don't use
>-j, there's only one processor and it doesn't help). I can happily read
>mail, run windows to remote machines to do admin, check web based
>monitors, and generally use the system. It's not a ball of fire, but
>it's old and slow moving, and I can identify with that ;-)
>
>| 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.
>
>Clearly your timeslices don't get so large the system suffers. And I can
>run setiathome with a little nice, like -5, and it will get some time
>without slowing the important stuff on the system. Even at -19 it does
>keep going. On a small memory machine I hate to give pages to a process
>without giving it the CPU to justify the memory.
>
>I'm going to try test5-n15 against test5-mm4 and test6-std with a server
>load, but for now I run your patch on machines I use as personal
>workstations. I haven't tried it SMP, that day will come.
>

Oh ok, yeah. It does look like it might need some work to prevent
timeslices from getting too small. I'm going to start working on this
soon.