Re: [RFC][PATCH 8/9] sched: power: Add initial frequency scaling support to power scheduler

[Arjan van de Ven <arjan@linux.intel.com>]

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.

>