linux-kernel - Re: [RFC 3/4] ARM: topology: Update cpu

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]

Date:	Wed, 13 Jun 2012 18:14:32 +0530
From:	Amit Kucheria <amit.kucheria@...aro.org>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	Jean Pihet <jean.pihet@...oldbits.com>, linux@....linux.org.uk,
	peterz@...radead.org, devicetree-discuss@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, rob.herring@...xeda.com,
	linaro-dev@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 3/4] ARM: topology: Update cpu_power according to DT information

On Wed, Jun 13, 2012 at 3:14 PM, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
> On 13 June 2012 10:59, Jean Pihet <jean.pihet@...oldbits.com> wrote:
>> Vincent,
>>
>> On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
>> <vincent.guittot@...aro.org> wrote:
>>> Use cpu compatibility field and clock-frequency field of DT to
>>> estimate the capacity of each core of the system
>>>
>>> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
>>> ---
>>>  arch/arm/kernel/topology.c |  122 ++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 122 insertions(+)
>>>
>>> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
>>> index 2f85a64..0c2aee4 100644
>>> --- a/arch/arm/kernel/topology.c
>>> +++ b/arch/arm/kernel/topology.c
>>> @@ -17,6 +17,7 @@
>>>  #include <linux/percpu.h>
>>>  #include <linux/node.h>
>>>  #include <linux/nodemask.h>
>>> +#include <linux/of.h>
>>>  #include <linux/sched.h>
>>>
>>>  #include <asm/cputype.h>
>>> @@ -47,6 +48,122 @@ void set_power_scale(unsigned int cpu, unsigned long power)
>>>        per_cpu(cpu_scale, cpu) = power;
>>>  }
>>>
>>> +#ifdef CONFIG_OF
>>> +struct cpu_efficiency {
>>> +       const char *compatible;
>>> +       unsigned long efficiency;
>>> +};
>>> +
>>> +/*
>>> + * Table of relative efficiency of each processors
>>> + * The efficiency value must fit in 20bit. The final
>>> + * cpu_scale value must be in the range [1:2048[.
>> Typo here.
>
> I realize that I have use absolute value instead of SCHED_POWER_SCALE.
> The cpu_scale value must be in the range 0 < cpu_scale < 2*SCHED_POWER_SCALE
>
>>
>>> + * Processors that are not defined in the table,
>>> + * use the default SCHED_POWER_SCALE value for cpu_scale.
>>> + */
>>> +struct cpu_efficiency table_efficiency[] = {
>>> +       {"arm,cortex-a15", 3891},
>>> +       {"arm,cortex-a7",  2048},
>> How are those results measured or computed? Is this purely related to
>> the number crunching performance?
>
> These values are based on ARM's figures which say that Cortex-A15 is
> 1,9 faster than Cortex-A7 at same frequency. So the inputs are ARM's
> figures. Then, the absolute values are arbitrary with the constraint
> of being large enough for precision and small enough to make the
> computation in an unsigned long
>
>>
>> Also more generally what if the cores frequencies are changing?
>
> Up to now, the scheduler takes into account the maximum capacity of a
> core when it checks the load balance of the system.

Jean,

Various discussions around power-aware scheduling have amplified the
need for the scheduler to have some knowledge of DVFS. This would then
require the scheduler to track 'cpu_power' ( = max power) and perhaps
a new variable 'current_power' that is changed by the DVFS framework.

The first goal, though, is to make sure that the scheduler can handle
different cpu_power values due to asymmetric cores.

/Amit
--
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/