Re: [RFC][PATCH] O(1) Entitlement Based Scheduler

[Peter Williams <peterw@aurema.com>]

Andi Kleen wrote:
> Peter Williams <peterw@aurema.com> 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                peterw@aurema.com
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