Dear All
I am going through the EAS project work and trying to port them on my ARM based SMP system (3.10 Linux version) Could you please help me clarify, will EAS be helpful in terms of power/performance for SMP systems as well?
Thanks & Regards Nitish Ambastha
On 10/26/2015 04:42 PM, Nitish Ambastha wrote:
Dear All
Hi Nitish,
I am going through the EAS project work and trying to port them on my ARM based SMP system (3.10 Linux version) Could you please help me clarify, will EAS be helpful in terms of power/performance for SMP systems as well?
It depends on the topology (single/multi-cluster) and the cpufreq (per cpu/cluster frequency scaling)/cpuidle (per cpu/cluster power gating) capabilities of your platform. Could you share them with the list please?
Leo Yan (Linaro) is evaluating EAS on an dual-cluster SMP machine (hikey) with per-system !!! frequency scaling and per cpu power gating.
He already figured that some of the code paths in energy_aware_wake_cpu() have to be adapted to fully work for dual-cluster SMP systems (see email thread of 22/46 and 32/46 of EAS RFCv5 on LKML).
Do you really have to use 3.10? The back-port effort is IMHO way too high ...
-- Dietmar
[...]
On Mon, Nov 2, 2015 at 3:15 AM, Dietmar Eggemann dietmar.eggemann@arm.com wrote:
On 10/26/2015 04:42 PM, Nitish Ambastha wrote:
Dear All
Hi Nitish,
Hi Dietmar
Thanks for your response
I am going through the EAS project work and trying to port them on my ARM based SMP system (3.10 Linux version) Could you please help me clarify, will EAS be helpful in terms of power/performance for SMP systems as well?
It depends on the topology (single/multi-cluster) and the cpufreq (per cpu/cluster frequency scaling)/cpuidle (per cpu/cluster power gating) capabilities of your platform. Could you share them with the list please?
It is a quad core in-order ARM Cortex A7MP, single cluster SMP, with cluster frequency scaling and per cpu power gating. I don't think this topology will benefit from the energy model of scheduler as much as a heterogeneous system or a multi-cluster system
Leo Yan (Linaro) is evaluating EAS on an dual-cluster SMP machine (hikey) with per-system !!! frequency scaling and per cpu power gating.
He already figured that some of the code paths in energy_aware_wake_cpu() have to be adapted to fully work for dual-cluster SMP systems (see email thread of 22/46 and 32/46 of EAS RFCv5 on LKML).
Do you really have to use 3.10? The back-port effort is IMHO way too high
Actually I am trying to benchmark this on a mobile device board which is already running 3.10. I have just ported the patches from https://git.linaro.org/kernel/eas-backports.git (3.10 based repository) However, I could not get sched-dvfs related patches for 3.10, and the effort here is big. Could you please suggest me a better candidate to check for 3.10?
...
-- Dietmar
[...]
Thanks Nitish Ambastha
On 11/03/2015 12:24 PM, Nitish Ambastha wrote:
Do you really have to use 3.10? The back-port effort is IMHO way too high
Actually I am trying to benchmark this on a mobile device board which is already running 3.10. I have just ported the patches from https://git.linaro.org/kernel/eas-backports.git (3.10 based repository)
The stuff there is really out of date. It will not be useful for benchmarking.
However, I could not get sched-dvfs related patches for 3.10, and the effort here is big. Could you please suggest me a better candidate to check for 3.10?
I'm not aware of a 3.10 based sched-dvfs branch. AFAIK you'd have to backport both the latest EAS patch set as well as sched-dvfs.
thanks, Steve
Hi Nitish.
Thanks for your participation.
On 4 Nov 2015, at 01:54, Nitish Ambastha nits.ambastha@gmail.com wrote:
It is a quad core in-order ARM Cortex A7MP, single cluster SMP, with cluster frequency scaling and per cpu power gating. I don't think this topology will benefit from the energy model of scheduler as much as a heterogeneous system or a multi-cluster system
That may be the case (subject to evaluation). However, given that the EAS work in question (energy model driven task placement and scheduler driven DVFS) is where the community wants to go, it is worthwhile aligning with this work so long as there is no significant power-perf regression versus the status quo.
Looking at it from that PoV, it’s not only about whether there is benefit for a given topology, it’s about whether EAS cuts it when stacked up against what you currently have on that topology. Ultimately the goal is to get EAS to be the replacement for the status quo for any topology.
Of course, if by empirical evaluation it emerges that EAS is tanking things on a single cluster SMP design, then we should try and fix that.
Robin
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 03/11/15 20:24, Nitish Ambastha wrote:
On Mon, Nov 2, 2015 at 3:15 AM, Dietmar Eggemann dietmar.eggemann@arm.com wrote:
On 10/26/2015 04:42 PM, Nitish Ambastha wrote:
[...]
It depends on the topology (single/multi-cluster) and the cpufreq (per cpu/cluster frequency scaling)/cpuidle (per cpu/cluster power gating) capabilities of your platform. Could you share them with the list please?
It is a quad core in-order ARM Cortex A7MP, single cluster SMP, with cluster frequency scaling and per cpu power gating. I don't think this topology will benefit from the energy model of scheduler as much as a heterogeneous system or a multi-cluster system
True, but EAS has still to work correctly on a topology like this. Taking our synthetic workloads (e.g. 4 6,13,19-50% periodic tasks, described in EAS RFCv5 cover letter), EAS will probably be forced to spread the tasks more than on a dual-cluster machine, i.e. tending more towards operating on lower OPP's rather than packing on less cpus than available. The actual behaviour depends obviously on the amount of energy you save by putting a cpu into 'cpu off', i.e. on the 'power' parameter of the 'struct idle_state' vectors of your Energy Model (EM).
There is another problem with the current EAS solution on a single cluster system you should be aware of in case you want to try it on your platform.
The scheduler domain hierarchy on such an ARM system only contains one level (MC level). Its scheduler groups represent each a single cpu.
The EAS EM for such a platform would still have one 'struct capacity_state' vector for a cpu and one for the cluster itself. Since we attach the EM information onto the scheduler groups, there are no scheduler groups representing the cluster because the corresponding scheduler domain level (DIE) and its scheduler group are not needed for task scheduling.
So you need an extra patch to have a scheduler domain, containing a scheduler group which spawns all cpus in the system to which the 'struct capacity_state' vector for the cluster can be attached and which isn't used for task scheduling (!SD_LOAD_BALANCE). The cluster contribution is different for different OPPs and this information is needed for the energy_diff() function. This patch is not part of the EAS RFCv5 on LKML but I can provide it to you if needed.
Leo Yan (Linaro) is evaluating EAS on an dual-cluster SMP machine (hikey) with per-system !!! frequency scaling and per cpu power gating.
He already figured that some of the code paths in energy_aware_wake_cpu() have to be adapted to fully work for dual-cluster SMP systems (see email thread of 22/46 and 32/46 of EAS RFCv5 on LKML).
Do you really have to use 3.10? The back-port effort is IMHO way too high
Actually I am trying to benchmark this on a mobile device board which is already running 3.10. I have just ported the patches from https://git.linaro.org/kernel/eas-backports.git (3.10 based repository) However, I could not get sched-dvfs related patches for 3.10, and the effort here is big. Could you please suggest me a better candidate to check for 3.10?
It would be really helpful if you would be able to try EAS on your platform but I'm afraid the only way for you is to find a solution in which you can use a mainline or tip/sched/core kernel. A back-port to 3.10 in this stage of EAS is IMHO not feasible. Sorry.
[...]
-- Dietmar
Hi All
Thanks for your responses and am sorry for late
It's indeed a huge task to port this on my current platform with 3.10 flavour kernel :-) As of now, sched-dvfs and EM does not look feasible with this, and so have to drop the idea of backporting
I have to agree with Dietmar, I'll figure out if there is a way I can try a more recent kernel that could help me out
Thanks & Regards Nitish Ambastha
On Thu, Nov 5, 2015 at 9:49 PM, Dietmar Eggemann dietmar.eggemann@arm.com wrote:
On 03/11/15 20:24, Nitish Ambastha wrote:
On Mon, Nov 2, 2015 at 3:15 AM, Dietmar Eggemann dietmar.eggemann@arm.com wrote:
On 10/26/2015 04:42 PM, Nitish Ambastha wrote:
[...]
It depends on the topology (single/multi-cluster) and the cpufreq (per cpu/cluster frequency scaling)/cpuidle (per cpu/cluster power gating) capabilities of your platform. Could you share them with the list please?
It is a quad core in-order ARM Cortex A7MP, single cluster SMP, with cluster frequency scaling and per cpu power gating. I don't think this topology will benefit from the energy model of scheduler as much as a heterogeneous system or a multi-cluster system
True, but EAS has still to work correctly on a topology like this. Taking our synthetic workloads (e.g. 4 6,13,19-50% periodic tasks, described in EAS RFCv5 cover letter), EAS will probably be forced to spread the tasks more than on a dual-cluster machine, i.e. tending more towards operating on lower OPP's rather than packing on less cpus than available. The actual behaviour depends obviously on the amount of energy you save by putting a cpu into 'cpu off', i.e. on the 'power' parameter of the 'struct idle_state' vectors of your Energy Model (EM).
There is another problem with the current EAS solution on a single cluster system you should be aware of in case you want to try it on your platform.
The scheduler domain hierarchy on such an ARM system only contains one level (MC level). Its scheduler groups represent each a single cpu.
The EAS EM for such a platform would still have one 'struct capacity_state' vector for a cpu and one for the cluster itself. Since we attach the EM information onto the scheduler groups, there are no scheduler groups representing the cluster because the corresponding scheduler domain level (DIE) and its scheduler group are not needed for task scheduling.
So you need an extra patch to have a scheduler domain, containing a scheduler group which spawns all cpus in the system to which the 'struct capacity_state' vector for the cluster can be attached and which isn't used for task scheduling (!SD_LOAD_BALANCE). The cluster contribution is different for different OPPs and this information is needed for the energy_diff() function. This patch is not part of the EAS RFCv5 on LKML but I can provide it to you if needed.
Leo Yan (Linaro) is evaluating EAS on an dual-cluster SMP machine (hikey) with per-system !!! frequency scaling and per cpu power gating.
He already figured that some of the code paths in energy_aware_wake_cpu() have to be adapted to fully work for dual-cluster SMP systems (see email thread of 22/46 and 32/46 of EAS RFCv5 on LKML).
Do you really have to use 3.10? The back-port effort is IMHO way too high
Actually I am trying to benchmark this on a mobile device board which is already running 3.10. I have just ported the patches from https://git.linaro.org/kernel/eas-backports.git (3.10 based repository) However, I could not get sched-dvfs related patches for 3.10, and the effort here is big. Could you please suggest me a better candidate to check for 3.10?
It would be really helpful if you would be able to try EAS on your platform but I'm afraid the only way for you is to find a solution in which you can use a mainline or tip/sched/core kernel. A back-port to 3.10 in this stage of EAS is IMHO not feasible. Sorry.
[...]
-- Dietmar
-
Dietmar Eggemann -
Nitish Ambastha -
Robin Randhawa -
Steve Muckle