sched.c : procfs tunables
Proper scheduling in a multi-tasking environment is critical to the success of a desktop OS. Linux, being mainly a server OS, is currently tuned to scheduling defaults that may be appropriate only for the server scenario.
To enable Linux to play an effective role on the desktop, a more flexible approach is necessary. An approach that would allow the end-User the freedom to adjust the OS to the specific environment at hand.
So instead of forcing a one-size fits all approach on the end-User, would not exporting sched.c tunables to the procfs present a flexible approach to the scheduling dilemma?
All comments that have a vested interest in enabling Linux on the desktop are most welcome, even if they describe other/better/smarter approaches.
Thanks!
--
Al
Quoted 8 lines · Al Boldi
Proper scheduling in a multi-tasking environment is critical to the success of a desktop OS. Linux, being mainly a server OS, is currently tuned to scheduling defaults that may be appropriate only for the server scenario.
To enable Linux to play an effective role on the desktop, a more flexible approach is necessary. An approach that would allow the end-User the freedom to adjust the OS to the specific environment at hand.
Quoted 6 lines
So instead of forcing a one-size fits all approach on the end-User, would not exporting
sched.ctunables to the procfs present a flexible approach to the scheduling dilemma?All comments that have a vested interest in enabling Linux on the desktop are most welcome, even if they describe other/better/smarter approaches.
None of the current "tunables" have easily understandable heuristics. Even those that appear to be obvious, like timselice, are not. While exporting tunables is not a bad idea, exporting tunables that noone understands is not really helpful. Even with heavy documentation, changes are not immediately predictable, and parts of the scheduler "know" about the default tuning values and they'd be broken by modifying them. Other scheduler designs, or more infrastructure on the current one (like what Mike's working on) might make some more obvious tunables. I've already discussed what I think in that regard too on a similar email thread. Exporting them also incurs a not insignificant cost.
Cheers,
Con
Quoted 15 lines · Con Kolivas
Quoted 14 lines · Al Boldi
Proper scheduling in a multi-tasking environment is critical to the success of a desktop OS. Linux, being mainly a server OS, is currently tuned to scheduling defaults that may be appropriate only for the server scenario.
To enable Linux to play an effective role on the desktop, a more flexible approach is necessary. An approach that would allow the end-User the freedom to adjust the OS to the specific environment at hand.
So instead of forcing a one-size fits all approach on the end-User, would not exporting
sched.ctunables to the procfs present a flexible approach to the scheduling dilemma?
Quoted 8 lines
Quoted 3 lines
All comments that have a vested interest in enabling Linux on the desktop are most welcome, even if they describe other/better/smarter approaches.
None of the current "tunables" have easily understandable heuristics. Even those that appear to be obvious, like timselice, are not. While exporting tunables is not a bad idea, exporting tunables that noone understands is not really helpful.
Couldn't this be fixed with an autotuning module based on cpu/mem/ctxt performance?
Quoted 3 lines · Mike Galbraith
Nope, not the existing tunables anyway. The full effect of even a tiny scheduler knob tweak is hard to predict even if you've studied the code carefully. These knobs are just not generic enough to be exposed IMHO.
Are you implying that the code is built around these tunables rather than using them?
Thanks!
--
Al
Quoted 8 lines · Al Boldi
Quoted 4 lines · Con Kolivas
None of the current "tunables" have easily understandable heuristics. Even those that appear to be obvious, like timselice, are not. While exporting tunables is not a bad idea, exporting tunables that noone understands is not really helpful.
Couldn't this be fixed with an autotuning module based on cpu/mem/ctxt performance?
You're assuming there is some meaningful relationship between changes in cpu/mem/ctxt performance and these tunables, which isn't the case. Furthermore if this was the case, noone understands it, can predict it or know how to tune it. Just saying "autotune it" doesn't really tell us how exactly the change those tunables in relation to the other variables. Since Mike and I understand them reasonably well I think we'd both agree that there is no meaningful association.
Cheers,
Con
Quoted 10 lines · Con Kolivas
Quoted 8 lines · Al Boldi
Quoted 4 lines · Con Kolivas
None of the current "tunables" have easily understandable heuristics. Even those that appear to be obvious, like timselice, are not. While exporting tunables is not a bad idea, exporting tunables that noone understands is not really helpful.
Couldn't this be fixed with an autotuning module based on cpu/mem/ctxt performance?
Quoted 7 lines
You're assuming there is some meaningful relationship between changes in cpu/mem/ctxt performance and these tunables, which isn't the case. Furthermore if this was the case, noone understands it, can predict it or know how to tune it. Just saying "autotune it" doesn't really tell us how exactly the change those tunables in relation to the other variables. Since Mike and I understand them reasonably well I think we'd both agree that there is no meaningful association.
After playing w/ these tunables it occurred to me that they are really only deadline limits, w/ a direct relation to cpu/mem/ctxt perf.
i.e timeslice=1 on i386sx means something other than timeslice=1 on amd64
It follows that w/o autotuning, the static default values have to be selected to allow for a large underlying perf range w/ a preference for the high range. This is also the reason why 2.6 feels really crummy on low perf ranges.
Autotuning the default values would allow to tighten this range specific to the hw used, thus allowing for a smoother desktop experience.
Thanks!
--
Al
Quoted 29 lines · Al Boldi
Quoted 16 lines · Con Kolivas
Quoted 13 lines · Al Boldi
Quoted 6 lines · Con Kolivas
None of the current "tunables" have easily understandable heuristics. Even those that appear to be obvious, like timselice, are not. While exporting tunables is not a bad idea, exporting tunables that noone understands is not really helpful.
Couldn't this be fixed with an autotuning module based on cpu/mem/ctxt performance?
Quoted 9 lines
You're assuming there is some meaningful relationship between changes in cpu/mem/ctxt performance and these tunables, which isn't the case. Furthermore if this was the case, noone understands it, can predict it or know how to tune it. Just saying "autotune it" doesn't really tell us how exactly the change those tunables in relation to the other variables. Since Mike and I understand them reasonably well I think we'd both agree that there is no meaningful association.
Quoted 7 lines
After playing w/ these tunables it occurred to me that they are really only deadline limits, w/ a direct relation to cpu/mem/ctxt perf.
i.e timeslice=1 on i386sx means something other than timeslice=1 on amd64
It follows that w/o autotuning, the static default values have to be selected to allow for a large underlying perf range w/ a preference for the high range. This is also the reason why 2.6 feels really crummy on low perf ranges.
Actually the lower HZ has something to do with that, and tuning swappiness can also help a lot.
Quoted 2 lines
Autotuning the default values would allow to tighten this range specific to the hw used, thus allowing for a smoother desktop experience.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 7 lines · Al Boldi
Quoted 3 lines · Mike Galbraith
Nope, not the existing tunables anyway. The full effect of even a tiny scheduler knob tweak is hard to predict even if you've studied the code carefully. These knobs are just not generic enough to be exposed IMHO.
Are you implying that the code is built around these tunables rather than using them?
I'm not implying anything, I'm merely stating my opinion: these knobs have subtle effects which render them unsuitable for export.
-Mike
Quoted 11 lines · Al Boldi
Proper scheduling in a multi-tasking environment is critical to the success of a desktop OS. Linux, being mainly a server OS, is currently tuned to scheduling defaults that may be appropriate only for the server scenario.
To enable Linux to play an effective role on the desktop, a more flexible approach is necessary. An approach that would allow the end-User the freedom to adjust the OS to the specific environment at hand.
So instead of forcing a one-size fits all approach on the end-User, would not exporting
sched.ctunables to the procfs present a flexible approach to the scheduling dilemma?
Nope, not the existing tunables anyway. The full effect of even a tiny scheduler knob tweak is hard to predict even if you've studied the code carefully. These knobs are just not generic enough to be exposed IMHO.
-Mike
Quoted 3 lines · Al Boldi
Proper scheduling in a multi-tasking environment is critical to the success of a desktop OS. Linux, being mainly a server OS, is currently tuned to scheduling defaults that may be appropriate only for the server scenario.
I'm not sure I would agree about distribution kernels, and kernel.org kernels certainly have the options to trade overhead for more response.
Quoted 5 lines
To enable Linux to play an effective role on the desktop, a more flexible approach is necessary. An approach that would allow the end-User the freedom to adjust the OS to the specific environment at hand.
So instead of forcing a one-size fits all approach on the end-User, would not exporting
sched.ctunables to the procfs present a flexible approach to the scheduling dilemma?
Let me agree with Mike and Con, I understand just well enough to pretty much leave them alone. The swappiness is available, that's one of the things which wants tuning. But the old 2.2 kernels did run better on small machines, even a stripped 2.6 kernel is slower.
Quoted 14 lines
All comments that have a vested interest in enabling Linux on the desktop are most welcome, even if they describe other/better/smarter approaches.
Thanks!
--
Al-
To unsubscribe from this list: send the line "unsubscribe linux-smp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979