Re: Linux 2.6.0-test6

[Nick Piggin]

bill davidsen wrote:

> In article <3F78D866.5070605@xxxxxxxxxxxxxxx>,
> Nick Piggin  <piggin@xxxxxxxxxxxxxxx> wrote:
> | 
> | 
> | bill davidsen wrote:
> | 
> | >In article <3F77BB2C.7030402@xxxxxxxxxxxxxxx>,
> | >Nick Piggin  <piggin@xxxxxxxxxxxxxxx> 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.


-
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/