* [RFC] sched.c : procfs tunables
@ 2006-03-31 14:23 Al Boldi
2006-03-31 14:44 ` Con Kolivas
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Al Boldi @ 2006-03-31 14:23 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-smp
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-03-31 14:23 [RFC] sched.c : procfs tunables Al Boldi
@ 2006-03-31 14:44 ` Con Kolivas
2006-04-03 11:59 ` Al Boldi
2006-04-01 2:49 ` Mike Galbraith
2006-04-07 2:57 ` Bill Davidsen
2 siblings, 1 reply; 9+ messages in thread
From: Con Kolivas @ 2006-03-31 14:44 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, linux-smp
On Saturday 01 April 2006 00:23, Al Boldi wrote:
> 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.
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-03-31 14:23 [RFC] sched.c : procfs tunables Al Boldi
2006-03-31 14:44 ` Con Kolivas
@ 2006-04-01 2:49 ` Mike Galbraith
2006-04-07 2:57 ` Bill Davidsen
2 siblings, 0 replies; 9+ messages in thread
From: Mike Galbraith @ 2006-04-01 2:49 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, linux-smp
On Fri, 2006-03-31 at 17:23 +0300, Al Boldi wrote:
> 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?
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-03-31 14:44 ` Con Kolivas
@ 2006-04-03 11:59 ` Al Boldi
2006-04-03 12:21 ` Con Kolivas
2006-04-03 12:43 ` Mike Galbraith
0 siblings, 2 replies; 9+ messages in thread
From: Al Boldi @ 2006-04-03 11:59 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel, linux-smp, Mike Galbraith
Con Kolivas wrote:
> On Saturday 01 April 2006 00:23, Al Boldi wrote:
> > 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.
>
> 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?
Mike Galbraith wrote:
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-04-03 11:59 ` Al Boldi
@ 2006-04-03 12:21 ` Con Kolivas
2006-04-04 13:27 ` Al Boldi
2006-04-03 12:43 ` Mike Galbraith
1 sibling, 1 reply; 9+ messages in thread
From: Con Kolivas @ 2006-04-03 12:21 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, linux-smp, Mike Galbraith
On Monday 03 April 2006 21:59, Al Boldi wrote:
> Con Kolivas wrote:
> > 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-04-03 11:59 ` Al Boldi
2006-04-03 12:21 ` Con Kolivas
@ 2006-04-03 12:43 ` Mike Galbraith
1 sibling, 0 replies; 9+ messages in thread
From: Mike Galbraith @ 2006-04-03 12:43 UTC (permalink / raw)
To: Al Boldi; +Cc: Con Kolivas, linux-kernel, linux-smp
On Mon, 2006-04-03 at 14:59 +0300, Al Boldi wrote:
> Mike Galbraith wrote:
> > 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-04-03 12:21 ` Con Kolivas
@ 2006-04-04 13:27 ` Al Boldi
2006-04-07 2:47 ` Bill Davidsen
0 siblings, 1 reply; 9+ messages in thread
From: Al Boldi @ 2006-04-04 13:27 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel, linux-smp, Mike Galbraith
Con Kolivas wrote:
> On Monday 03 April 2006 21:59, Al Boldi wrote:
> > Con Kolivas wrote:
> > > 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.
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-04-04 13:27 ` Al Boldi
@ 2006-04-07 2:47 ` Bill Davidsen
0 siblings, 0 replies; 9+ messages in thread
From: Bill Davidsen @ 2006-04-07 2:47 UTC (permalink / raw)
To: Al Boldi; +Cc: Con Kolivas, linux-kernel, linux-smp, Mike Galbraith
Al Boldi wrote:
>Con Kolivas wrote:
>
>
>>On Monday 03 April 2006 21:59, Al Boldi wrote:
>>
>>
>>>Con Kolivas wrote:
>>>
>>>
>>>>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.
>>
>>
>
>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.
>Autotuning the default values would allow to tighten this range specific to
>the hw used, thus allowing for a smoother desktop experience.
>
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] sched.c : procfs tunables
2006-03-31 14:23 [RFC] sched.c : procfs tunables Al Boldi
2006-03-31 14:44 ` Con Kolivas
2006-04-01 2:49 ` Mike Galbraith
@ 2006-04-07 2:57 ` Bill Davidsen
2 siblings, 0 replies; 9+ messages in thread
From: Bill Davidsen @ 2006-04-07 2:57 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, linux-smp
Al Boldi wrote:
>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.
>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?
>
>
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.
>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 majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-04-07 2:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-31 14:23 [RFC] sched.c : procfs tunables Al Boldi
2006-03-31 14:44 ` Con Kolivas
2006-04-03 11:59 ` Al Boldi
2006-04-03 12:21 ` Con Kolivas
2006-04-04 13:27 ` Al Boldi
2006-04-07 2:47 ` Bill Davidsen
2006-04-03 12:43 ` Mike Galbraith
2006-04-01 2:49 ` Mike Galbraith
2006-04-07 2:57 ` Bill Davidsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).