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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51E022BA.9030005@linux.intel.com>
Date:	Fri, 12 Jul 2013 08:37:30 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Morten Rasmussen <morten.rasmussen@....com>
CC:	"mingo@...nel.org" <mingo@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	"alex.shi@...el.com" <alex.shi@...el.com>,
	"efault@....de" <efault@....de>, "pjt@...gle.com" <pjt@...gle.com>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"corbet@....net" <corbet@....net>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>
Subject: Re: [RFC][PATCH 8/9] sched: power: Add initial frequency scaling
 support to power scheduler

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@....com>
>>> CC: Ingo Molnar <mingo@...nel.org>
>>> CC: Peter Zijlstra <peterz@...radead.org>
>>> CC: Catalin Marinas <catalin.marinas@....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.

>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/