Re: [Eas-dev] Energy Model Question

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>