On 7/12/2013 5:51 AM, Morten Rasmussen wrote:
On Wed, Jul 10, 2013 at 02:10:59PM +0100, Arjan van de Ven wrote:
On 7/9/2013 8:55 AM, Morten Rasmussen wrote:
Extends the power scheduler capacity management algorithm to handle frequency scaling and provide basic frequency/P-state selection hints to the power driver.
Signed-off-by: Morten Rasmussen morten.rasmussen@arm.com CC: Ingo Molnar mingo@kernel.org CC: Peter Zijlstra peterz@infradead.org CC: Catalin Marinas catalin.marinas@arm.com
kernel/sched/power.c | 33 ++++++++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/power.c b/kernel/sched/power.c index 9e44c0e..5fc32b0 100644 --- a/kernel/sched/power.c +++ b/kernel/sched/power.c @@ -21,6 +21,8 @@
#define INTERVAL 5 /* ms */ #define CPU_FULL 90 /* Busy %-age - TODO: Make tunable */ +#define CPU_TARGET 80 /* Target busy %-age - TODO: Make tunable */ +#define CPU_EMPTY 5 /* Idle noise %-age - TODO: Make tunable */
to be honest, this is the policy part that really should be in the hardware specific driver and not in the scheduler. (even if said driver is sort of a "generic library" kind of thing)
I agree that the values should be set by a hardware specific power driver. Or do you mean that algorithms using this sort of values should be in the driver?
the later. the algorithm you have makes assumptions about how the hardware behaves to a degree that is really problematic. It sort of seems to resemble the ondemand kind of thing.... ... and there's some very good reasons we ran away screaming from ondemand for Intel.