Hi Valentin,
I would like to check whether I have understood what you mentioned. Based on the following Hikey Big cluster core, https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-...
50 - 'Active' idle state 50 - WFI 15 - cpu-nap 0 - cpu-sleep 0 - cluster-sleep
Would the above order be correct?
Also, what exactly do the idle-cost-data values mean? Do they refer to the cost of maintaining the core/cluster at that idle state, or the cost to put/exit the core/cluster into the idle state?
Thanks, Josh
On Wed, Sep 13, 2017 at 7:34 PM, Valentin Schneider < valentin.schneider@arm.com> wrote:
Hi,
Brendan beat me to it - I don't have much to add apart from some examples using the HiKey960
On 09/13/2017 11:39 AM, Brendan Jackman wrote:
Hi Zachariah,
On Tue, Sep 12 2017 at 23:09, Zachariah Kennedy wrote:
Good day!
Been really enjoying watching development of eas on Android Gerrit and in other places so first let me say thanks again for all the great work.
With that, I had a couple questions about idle states in the energy model. I am mainly curious about the number of tuples used for the idle states. On the Pixel they used "2 2 0" for the CPU Idle States, I would think that would be for:
wfi fpc-def fpc
But for Cluster Idle states they used "0 0" but I would think there should be 3 tuples since the Cluster Idle States are:
l2-wfi l2-gdhs l2-fpc
So why only the two "0 0" for the Pixel EM?
I believe there may have been a bug here at some point, that happened not to make any difference - anyone else remember?
I wasn't around for the Pixel bring-up, but I do think I heard there was a bug there.
Now this leads up to my ultimate question and that is about the SD835
(from the OnePlus5)
For CPU Idle States we have:
wfi ret pc
But we disable idle_enable for "ret". So would this mean that in my own EM for the OP5 I should only have 2 tuples?
And for Cluster Idle States we have:
l2-wfi l2-dynret l2-ret l2-pc
But on the OP5 we disable l2-dynret and l2-ret. So once again, should I only have 2 tuples for the number of idle states used or a tuple for each physical idle state possible?
I'll use the HiKey960 as a reference:
First, let's look at the idle states: https://android.googlesource.com/kernel/hikey-linaro/+/andro id-hikey-linaro-4.4/arch/arm64/boot/dts/hisilicon/hi3660.dtsi#98 on the LITTLE side we have:
- WFI (unlisted)
- cpu-sleep
- cluster-sleep
on the big side we have:
- WFI (unlisted)
- cpu-nap
- cpu-sleep
- cluster-sleep
Now let's have a look at the energy model: https://android.googlesource.com/kernel/hikey-linaro/+/andro id-hikey-linaro-4.4/arch/arm64/boot/dts/hisilicon/hi3660-sched-energy.dtsi Here we can see that we have (nr_idle_states + 1) entries in the idle-cost-data section.
This is tied to how we compute energy costs - let's have a look at sched_group_energy(): https://android.googlesource.com/kernel/hikey-linaro/+/andro id-hikey-linaro-4.4/kernel/sched/fair.c#5531 The current idle state is needed, so group_idle_state() is called: https://android.googlesource.com/kernel/hikey-linaro/+/andro id-hikey-linaro-4.4/kernel/sched/fair.c#5400 And here you can see that we increment by one the value used for idle state.
(this is is pretty much a rephrasing of what Brendan said...) This is mostly done to make computation easier: non-idling ("active") idle state index is -1, so we bring that up to 0 to avoid having to deal with negative numbers. We also have some cases were we can have idle_idx==0 but group_util < 1024, so sched_group_energy() will try to compute the cost of idling. It does so by using the idle-cost value indexed by idle_idx. That is why there is an additional "active" entry in idle-cost-data, which here is just a duplicate of WFI.
The index into the idle states array that is used by the energy model
calculation is derived from idle_get_state_idx (plus some heuristics) as you can see here:
https://android.googlesource.com/kernel/common/+/android-4.4 /kernel/sched/fair.c#5400
So the number of entries in your idle-states array depends on range of that' function's return value - I guess you'll need to dig into cpuidle to figure out what that actually means for your case.
One of the important things to note in the code I linked above is:
/* Take non-cpuidle idling into account (activeidle/arch_cpu_idle()) */ state++;
What that is referring to is that idle_get_state_idx will return -1 if the CPU is currently not idle, and what EAS does is treat that as the shallowest idle state when calculating the idle power component. That means that if there are 3 idle states (i.e. idle_get_state_idx can return 0, 1 or 2) then you actually need 4 entries in your idle states array, where the first and second are the exact same. This isn't the prettiest corner of EAS I'm afraid :)
Hope that's helpful..
Brendan _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev