Good day!
I have noticed since release that EM for the Pixel 2 doesnt cover each frequency step. 22 steps for small cores, 31 steps for big cores.
There are 22 tuples for the small cores but only 27 tuples for big cores.
I have checked and the Pixel 2 is using all frequency steps for both small and big cores, so why doesnt the EM account for the last 4 freq steps for big cores?
Thanks as always for taking the time to answer my questions.
Kind Regards, Zachariah Kennedy
On 28-Nov 10:02, Zachariah Kennedy wrote:
Good day!
Hi Zachariah,
I have noticed since release that EM for the Pixel 2 doesnt cover each frequency step. 22 steps for small cores, 31 steps for big cores.
There are 22 tuples for the small cores but only 27 tuples for big cores.
I have checked and the Pixel 2 is using all frequency steps for both small and big cores, so why doesnt the EM account for the last 4 freq steps for big cores?
Currently the EM tables are populated in the DT using a dedicated set of binding: https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1... which is different from the bindings defining the OPPs: https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1...
As you can see, also in the public available kernel these two tables are misaligned: the reported OPPs are 25 while we have 27 entries in the EM.
There are not reasons why the EM table should be misaligned wrt the OPP table, thus I guess that this happened because of some optimizations (likely in the OPP list) done after the EM has been created, without updating accordingly the EM bindings.
From a functional standpoint however this should not have a big impact
on the Energy Aware scheduler. To put it simple, the point is that once the system is working on these high OPPs we are already over what is called "the tipping point" (i.e. 80% of the max capacity) and the scheduler is not more working in EAS mode (i.e. we do not use the EM).
Thus, although the missing of the highest OPPs is something that should be fixes for "consistency reasons", what we have now is not affecting the EA behaviors of the system (i.e. when running medium-low workloads).
Thanks as always for taking the time to answer my questions.
Thanks for reporting this!
-- #include <best/regards.h>
Patrick Bellasi
Thanks for the prompt response and keep up the great work!
Kind Regards, Zachariah Kennedy
On Tue, Nov 28, 2017 at 12:48 PM, Patrick Bellasi patrick.bellasi@arm.com wrote:
On 28-Nov 10:02, Zachariah Kennedy wrote:
Good day!
Hi Zachariah,
I have noticed since release that EM for the Pixel 2 doesnt cover each frequency step. 22 steps for small cores, 31 steps for big cores.
There are 22 tuples for the small cores but only 27 tuples for big cores.
I have checked and the Pixel 2 is using all frequency steps for both
small
and big cores, so why doesnt the EM account for the last 4 freq steps for big cores?
Currently the EM tables are populated in the DT using a dedicated set of binding: https://android.googlesource.com/kernel/msm/+/android-msm- wahoo-4.4-oreo-dr1/arch/arm/boot/dts/qcom/msm8998.dtsi#282 which is different from the bindings defining the OPPs: https://android.googlesource.com/kernel/msm/+/android-msm- wahoo-4.4-oreo-dr1/arch/arm/boot/dts/qcom/msm8998.dtsi#849
As you can see, also in the public available kernel these two tables are misaligned: the reported OPPs are 25 while we have 27 entries in the EM.
There are not reasons why the EM table should be misaligned wrt the OPP table, thus I guess that this happened because of some optimizations (likely in the OPP list) done after the EM has been created, without updating accordingly the EM bindings.
From a functional standpoint however this should not have a big impact on the Energy Aware scheduler. To put it simple, the point is that once the system is working on these high OPPs we are already over what is called "the tipping point" (i.e. 80% of the max capacity) and the scheduler is not more working in EAS mode (i.e. we do not use the EM).
Thus, although the missing of the highest OPPs is something that should be fixes for "consistency reasons", what we have now is not affecting the EA behaviors of the system (i.e. when running medium-low workloads).
Thanks as always for taking the time to answer my questions.
Thanks for reporting this!
-- #include <best/regards.h>
Patrick Bellasi
-
Patrick Bellasi -
Zachariah Kennedy