On Fri, Jul 12, 2013 at 01:51:13PM +0100, 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?
I think for flexibility we could place the default algorithm in a library and it would be used by the cpufreq power driver wrapper or directly by a new power driver. The intel_pstate.c driver could be allowed to do smarter things.