Re: [RFC][PATCH 8/9] sched: power: Add initial frequency scalingsupport to power scheduler
From: Arjan van de Ven
Date: Fri Jul 12 2013 - 11:37:55 EST
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@xxxxxxx>
CC: Ingo Molnar <mingo@xxxxxxxxxx>
CC: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
CC: Catalin Marinas <catalin.marinas@xxxxxxx>
---
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/