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?
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?
Kind Regards, Zachariah Kennedy
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?
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?
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/fa...
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 (active idle/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
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/+/android-hikey-linaro-... 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/+/android-hikey-linaro-... 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/+/android-hikey-linaro-... The current idle state is needed, so group_idle_state() is called: https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-... 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/fa...
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 (active idle/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
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 (active
idle/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
Hi Joshua,
On Fri, Sep 15, 2017 at 12:55:33AM +0800, Joshua Choo wrote:
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?
Yes.
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?
For upper array, they refer to the cost of maintaining the core at that idle state. There have another array data to maintain cluster level data: https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-...
Thanks, Leo Yan
Once again late to the party, I just saw Leo's mail arrive as I was about to send this one...
On 09/14/2017 05:55 PM, Joshua Choo wrote:
Hi Valentin,
Hi,
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?
That looks good to me. Also, going back to Zachariah's mail - even if you disable some idle states, their index will not change so you should still list them in the energy model.
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?
I'd say it's the former rather than the latter. You can have a look at the energy computation here: https://android.googlesource.com/kernel/hikey-linaro/+/android-hikey-linaro-... What is done here is, in short, (busy_cost * busy_time) + (idle_cost * idle_time) - no transition costs here.
If you have a look at the Notebook we use to generate energy models (https://github.com/ARM-software/lisa/blob/master/ipynb/energy/EnergyModel_Sy...), you'll see that we get idle costs by forcing the CPUs in a certain idle state and averaging the measured energy consumption of the system. Mind you, I've been trying to improve/simplify that Notebook using the HiKey960 - while I get decent results for busy costs, I still have issues with idle costs.
Thanks, Josh
On Wed, Sep 13, 2017 at 7:34 PM, Valentin Schneider <valentin.schneider@arm.com mailto: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/+/android-hikey-linaro-4.4/arch/arm64/boot/dts/hisilicon/hi3660.dtsi#98 <https://android.googlesource.com/kernel/hikey-linaro/+/android-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/+/android-hikey-linaro-4.4/arch/arm64/boot/dts/hisilicon/hi3660-sched-energy.dtsi <https://android.googlesource.com/kernel/hikey-linaro/+/android-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/+/android-hikey-linaro-4.4/kernel/sched/fair.c#5531 <https://android.googlesource.com/kernel/hikey-linaro/+/android-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/+/android-hikey-linaro-4.4/kernel/sched/fair.c#5400 <https://android.googlesource.com/kernel/hikey-linaro/+/android-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 <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 (active idle/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 <mailto:eas-dev@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/eas-dev <https://lists.linaro.org/mailman/listinfo/eas-dev> _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org <mailto:eas-dev@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/eas-dev <https://lists.linaro.org/mailman/listinfo/eas-dev>