Re: [RFC][PATCH] O(1) Entitlement Based Scheduler
From: Peter Williams (peterw_at_aurema.com)
Date: 03/03/04
- Previous message: Jesse Barnes: "Re: per-cpu blk_plug_list"
- In reply to: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Next in thread: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Reply: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Reply: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 03 Mar 2004 14:45:28 +1100 To: Andi Kleen <ak@suse.de>
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Jesse Barnes: "Re: per-cpu blk_plug_list"
- In reply to: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Next in thread: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Reply: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Reply: Andi Kleen: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
