Peter Williams <[email protected]> writes:
One comment on the patches: could you remove the zillions of numerical Kconfig
options and just make them sysctls? I don't think it makes any sense
to require a reboot to change any of that. And the user is unlikely
to have much idea yet on what he wants on them while configuring.
I really like the reduced scheduler complexity part of your patch BTW.
IMHO the 2.6 scheduler's complexity has gotten out of hand and it's great
that someone is going into the other direction with a simple basic design.
For more wide spread testing it would be useful if you could do
a more minimal less intrusive patch with less configuration
(e.g. only allow tuning via nice, not via other means). This would
be mainly to test your patch on more workloads without any hand tuning,
which is the most important use case.
-Andi
Andi Kleen wrote:
> Peter Williams <[email protected]> writes:
>
> One comment on the patches: could you remove the zillions of numerical Kconfig
> options and just make them sysctls? I don't think it makes any sense
> to require a reboot to change any of that. And the user is unlikely
> to have much idea yet on what he wants on them while configuring.
The default initial values should be fine and the default configuration
allows the scheduling tuning parameters (i.e. half life and time slice
) to be changed on a running system via the /proc file system.
These are mainly there so that different settings can be used with
various benchmarks to determine what are the best settings for various
types of loads. If good default values that work well for a wide
variety of load types can be found as a result of these experiments then
these parameters may be made constants in the code. If not they
probably should be made settable via system calls rather than via /proc
as you suggest.
In reality, batch type jobs tend to get better throughput with a longer
half life but a shorter half life gives better interactive response. So
servers and work stations should probably have different settings.
>
> I really like the reduced scheduler complexity part of your patch BTW.
> IMHO the 2.6 scheduler's complexity has gotten out of hand and it's great
> that someone is going into the other direction with a simple basic design.
Thanks, we felt much the same. With a heuristic approach there always
seems to be one more case that needs to be handled specially popping up.
>
> For more wide spread testing it would be useful if you could do
> a more minimal less intrusive patch with less configuration
> (e.g. only allow tuning via nice, not via other means). This would
> be mainly to test your patch on more workloads without any hand tuning,
> which is the most important use case.
The "base" patch does this except that it also allows the setting of
soft caps via /proc. But, as I said above, the main reason for the
tuning parameters being exposed (in the full patch) at this time is to
encourage testing with different values (of half life and time slice)
and making them settable via /proc makes this possible without having to
reboot the system.
Except for (possibly) renicing the X server there should be no need to
fiddle with settings for individual tasks.
Peter
PS We are looking at some simple modifications to further improve
interactive response (hopefully) without adding to complexity.
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
On Wed, Mar 03, 2004 at 02:45:28PM +1100, Peter Williams wrote:
> Andi Kleen wrote:
> >Peter Williams <[email protected]> writes:
> >
> >One comment on the patches: could you remove the zillions of numerical
> >Kconfig
> >options and just make them sysctls? I don't think it makes any sense
> >to require a reboot to change any of that. And the user is unlikely
> >to have much idea yet on what he wants on them while configuring.
>
> The default initial values should be fine and the default configuration
> allows the scheduling tuning parameters (i.e. half life and time slice
> ) to be changed on a running system via the /proc file system.
> These are mainly there so that different settings can be used with
> various benchmarks to determine what are the best settings for various
> types of loads. If good default values that work well for a wide
> variety of load types can be found as a result of these experiments then
> these parameters may be made constants in the code. If not they
> probably should be made settable via system calls rather than via /proc
> as you suggest.
No doubt that there are different settings that make sense
for different workloads. But there is no reason one has to recompile
to set them - it's much nicer to just run a script at boot time to set
them, instead of recompiling/rebooting. This will also make benchmarking
much easier, because you can just write a script that sets the
various parameters, runs workloads, sets other parameters, runs
workload again etc. Requiring a recompile and reboot makes this
much harder.
Also I suspect most people who are not heavily into scheduling
theory will go with the defaults at compile time, so it's important
that they already work well.
And consider it from the side of a standard distribution: users
don't normally recompile their kernels there, so everything that
makes sense to be tunable should be settable without recompiling.
IMHO CONFIG_* should not be used for anything except for kernel binary
size tuning and possible compiler tuning.
-Andi
On Wed, 03 Mar 2004 14:45:28 +1100
Peter Williams <[email protected]> wrote:
> Andi Kleen wrote:
> > Peter Williams <[email protected]> writes:
> >
> > One comment on the patches: could you remove the zillions of numerical Kconfig
> > options and just make them sysctls? I don't think it makes any sense
> > to require a reboot to change any of that. And the user is unlikely
> > to have much idea yet on what he wants on them while configuring.
>
> The default initial values should be fine and the default configuration
> allows the scheduling tuning parameters (i.e. half life and time slice
> ) to be changed on a running system via the /proc file system.
I'm running the 2.6.3-full patch on my workstation now. No tuning applied
at all. I reniced the X server to -10. When I have two kernel compiles (without any -j*)
running there is a visible (=not really slow, but long enough to notice something)
delay in responses while typing something in a xterm. In sylpheed there
is the same issue.
The standard scheduler didn't show this that extreme with only two compiles.
-Andi
Andi Kleen wrote:
> On Wed, Mar 03, 2004 at 02:45:28PM +1100, Peter Williams wrote:
>
>>Andi Kleen wrote:
>>
>>>Peter Williams <[email protected]> writes:
>>>
>>>One comment on the patches: could you remove the zillions of numerical
>>>Kconfig
>>>options and just make them sysctls? I don't think it makes any sense
>>>to require a reboot to change any of that. And the user is unlikely
>>>to have much idea yet on what he wants on them while configuring.
>>
>>The default initial values should be fine and the default configuration
>>allows the scheduling tuning parameters (i.e. half life and time slice
>> ) to be changed on a running system via the /proc file system.
>>These are mainly there so that different settings can be used with
>>various benchmarks to determine what are the best settings for various
>>types of loads. If good default values that work well for a wide
>>variety of load types can be found as a result of these experiments then
>>these parameters may be made constants in the code. If not they
>>probably should be made settable via system calls rather than via /proc
>>as you suggest.
>
>
> No doubt that there are different settings that make sense
> for different workloads. But there is no reason one has to recompile
> to set them - it's much nicer to just run a script at boot time to set
> them, instead of recompiling/rebooting. This will also make benchmarking
> much easier, because you can just write a script that sets the
> various parameters, runs workloads, sets other parameters, runs
> workload again etc. Requiring a recompile and reboot makes this
> much harder.
As I said (with the full patch) these values can be set via /proc on a
running system so there's no need for a recompile and reboot.
>
> Also I suspect most people who are not heavily into scheduling
> theory will go with the defaults at compile time, so it's important
> that they already work well.
>
> And consider it from the side of a standard distribution: users
> don't normally recompile their kernels there, so everything that
> makes sense to be tunable should be settable without recompiling.
>
> IMHO CONFIG_* should not be used for anything except for kernel binary
> size tuning and possible compiler tuning.
Yes, once this patch has stabilised we will probably remove some (or
all) of the configuration variables.
Peter
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
Andi Kleen wrote:
> On Wed, 03 Mar 2004 14:45:28 +1100
> Peter Williams <[email protected]> wrote:
>
>
>>Andi Kleen wrote:
>>
>>>Peter Williams <[email protected]> writes:
>>>
>>>One comment on the patches: could you remove the zillions of numerical Kconfig
>>>options and just make them sysctls? I don't think it makes any sense
>>>to require a reboot to change any of that. And the user is unlikely
>>>to have much idea yet on what he wants on them while configuring.
>>
>>The default initial values should be fine and the default configuration
>>allows the scheduling tuning parameters (i.e. half life and time slice
>> ) to be changed on a running system via the /proc file system.
>
>
> I'm running the 2.6.3-full patch on my workstation now. No tuning applied
> at all. I reniced the X server to -10. When I have two kernel compiles (without any -j*)
> running there is a visible (=not really slow, but long enough to notice something)
> delay in responses while typing something in a xterm. In sylpheed there
> is the same issue.
>
> The standard scheduler didn't show this that extreme with only two compiles.
>
Thanks for the feedback. We're looking at some minor modifications to
try and improve this issue.
BTW Could you try it with the X server reniced to -15?
Thanks
Peter
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
On Thu, 04 Mar 2004 11:41:00 +1100
Peter Williams <[email protected]> wrote:
> BTW Could you try it with the X server reniced to -15?
It seems to be a bit better with -15 (or maybe I'm imagining that), but still
noticeable.
-Andi