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