V-3.0 Single Priority Array O(1) CPU Scheduler Evaluation
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Peter Williams
Version 3 of the various single priority array scheduler patches for 2.6.7, 2.6.8-rc2 and 2.6.8-rc2-mm1 kernels are now available for download and evaluation:
[...] So many schedulers. It is hard to chose one for testing.
Do you have one you prefer and would like to be tested especially?
Perhaps a few standard benchmark numbers for the different ones (e.g. volanomark or hackbench or the OSDL SDL tests) would make it easier to preselect.
Have you considered submitting one to -mm* for wider testing?
-Andi
Quoted 11 lines · Andi Kleen
Quoted 3 lines · Peter Williams
Version 3 of the various single priority array scheduler patches for 2.6.7, 2.6.8-rc2 and 2.6.8-rc2-mm1 kernels are now available for download and evaluation:
[...] So many schedulers. It is hard to chose one for testing.
Do you have one you prefer and would like to be tested especially?
I think that ZAPHOD in "pb" mode is probably the best but I'm hoping for input from a wider audience. That's why I built HYDRA. So that various options can be tried without having to rebuild and reboot.
The questions I'm trying to answer are:
1. Are "priority" based ("pb") semantics for "nice" better than "entitlement" based ("eb") semantics? Does it depend on what the system's being used for?
2. What are the appropriate values for controlling interactive bonuses for "pb" and "eb"?
3. Are interactive bonuses even necessary for "eb"?
4. What's the best time slice size for interactive use?
5. What's the best time slice size for a server?
6. Does the throughput bonus help? In particular, does it reduce the amount of queuing when the system is not fully loaded.
7. Should any (or all) of the scheduling knobs in /proc/sys/kernel/cpusched/ be retained for a production scheduler.
Quoted 2 lines
Perhaps a few standard benchmark numbers for the different ones (e.g. volanomark or hackbench or the OSDL SDL tests) would make it easier to preselect.
OK, I'll do that. But some of the questions for which I am seeking answers are more subjective. In particular, interactive responsiveness is hard to test automatically.
Also, these tests are no good for evaluating the throughput bonus because when the system is heavily loaded there's going to be queuing anyway. Where this bonus is expected to be most helpful is at intermediate system loads where there is still significant queuing (due to lack of serendipity i.e. they're all sleeping at the same time and trying to run at the same time instead of slotting in nicely between each other) even though there are (theoretically) enough CPU resources to handle the load without any queuing. Tests with an earlier scheduler showed that (where such queuing was occurring) the techniques used in the throughput bonus could significantly reduce it. These tests were conducted with artificial loads and confirmation from the real world would be helpful. (Of import here is whether there are significant queuing problems at intermediate loads in the real world because if there isn't then there is nothing for the throughput bonus to fix. This is possible because the higher the randomness of a system's load then the better the serendipity will be.)
The scheduling statistics that are included in my patches measure time spent on the run queue so that measurements of improvements due to the throughput bonus are possible. Another way that such improvements would be increased responsiveness from servers.
Quoted 2 lines
Have you considered submitting one to -mm* for wider testing?
I've made patches available for 2.6.8-rc2-mm1 and I'll provide them for mm2 as soon as possible. Is there something else I should be doing?
Peter
Signature · 4 lines
Peter Williams [email protected] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce
Quoted 5 lines · Peter Williams
Quoted 2 lines
Have you considered submitting one to -mm* for wider testing?
I've made patches available for 2.6.8-rc2-mm1 and I'll provide them for mm2 as soon as possible. Is there something else I should be doing?
I'll probably drop staircase soon, give nicksched a whizz for a couple of cycles. You're welcome to join the queue ;)
But let me re-repeat again that CPU scheduler problems tend to take a _long_ time to turn up - you make some change and two months later some person with a weird workload on expensive hardware hits a nasty corner case. So I do think that we'd have to hit a nasty problem with the current scheduler to go making deep changes.
Although most of the fragility has been in CPU/node/HT balancing rather than in the timeslice allocation area. I assume you're not touching the former. It's the desktop users who seem to be more affected by the timeslice allocation algorithms, and the testing turnaround is much faster there.
Quoted 9 lines · Andrew Morton
Quoted 3 lines · Peter Williams
Quoted 1 line
Have you considered submitting one to -mm* for wider testing?
I've made patches available for 2.6.8-rc2-mm1 and I'll provide them for mm2 as soon as possible. Is there something else I should be doing?
I'll probably drop staircase soon, give nicksched a whizz for a couple of cycles. You're welcome to join the queue ;)
OK, thanks.
Quoted 10 lines
But let me re-repeat again that CPU scheduler problems tend to take a _long_ time to turn up - you make some change and two months later some person with a weird workload on expensive hardware hits a nasty corner case. So I do think that we'd have to hit a nasty problem with the current scheduler to go making deep changes.
Although most of the fragility has been in CPU/node/HT balancing rather than in the timeslice allocation area. I assume you're not touching the former.
Correct. No (algorithmic) changes have been made to load balancing type code. There have been some modifications so that my statistics gathering copes with a task moving to different CPU and some modifications due to changes in data structures but these should not change the way that load balancing etc. work.
Quoted 3 lines
It's the desktop users who seem to be more affected by the
timeslice allocation algorithms, and the testing turnaround is much faster there.
OK.
Peter
Signature · 4 lines
Peter Williams [email protected] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce
Quoted 5 lines
But let me re-repeat again that CPU scheduler problems tend to take a _long_ time to turn up - you make some change and two months later some person with a weird workload on expensive hardware hits a nasty corner case. So I do think that we'd have to hit a nasty problem with the current scheduler to go making deep changes.
How about just simplifying the code? Both Con's and Peter's code look a lot simpler compared to the stock scheduler and are easier to understand. If they don't work significantly worse I think that would be a strong argument to move to one of them.
-Andi