On 21/10/15 02:56, Leo Yan wrote:
Hi Dietmar,
On Tue, Oct 20, 2015 at 08:04:30PM +0100, Dietmar Eggemann wrote:
On 14/10/15 17:30, Leo Yan wrote:
Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | |---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
Measured raw data:
sys_suspend: AP system suspend state cluster_off: two clusters are powered off cluster_on: 1 cluster is powered on, all cpus are powered off cpu_wfi: 1 cluster is powered on, last cpu enters 'wfi' but other cpus are powered off voltage: voltage for every OPP
# OPP sys_suspend cluster_off cluster_on cpu_wfi cpu_on voltage 208 328 347 366 374 435 1.04 432 328 344 374 388 499 1.04 729 331 351 400 409 606 1.09 960 329 353 430 443 750 1.18 1200 331 365 486 506 988 1.33
Hikey Power ModelPower [mW] 500 ++--------+-------------+---------+---------++ cluster_off **A*** + + + + D cluster_on ##B### 450 ++.........................................%%+ cpu_wfi $$C$$$ 400 ++.......................................%%.++ cpu p-state %%D%%% | : : : %% | 350 ++...................................%%.....++ | : : :%% | 300 ++...............................%D.........++ 250 ++...........................%%%%...........++ | : : %%% : | 200 ++....................%%D%..................++ | : %%%%% : : | 150 ++...........%%%%...........................++ | %%D%% : : #####B 100 ++.%%%%%.....................#####B#####....++ 50 D%%..............#######B####...............++ A*********A*************A*********A**********A 0 C$$$$$$$$$C$$$$$$$$$$$$$C$$$$$$$$$C$$$$$----++ 208 432 729 960 1200 Frequency [MHz]
Hikey Power EfficiencyPower Efficiency [mW/MHz] Voltage [v] 0.45 ++-------+----------+--------+-------++ 3 Cluster Power **A*** + + + + + CPU Static Power ##B### 0.4 ++...................................$C CPU Dynamic power $$C$$$ | : : : $$$++ 2.5 Voltage %%D%%% 0.35 ++.............................$$$...++ | : : $$C$ | 0.3 C$$$$$$$$..............$$$$..........++ 2 | C$$$$$$$$$$C$$ : | 0.25 ++...................................++ 1.5 0.2 ++................................%%%%D | : : %%%%D%%%% | 0.15 D%%%%%%%%D%%%%%%%%%%D%%%%............++ 1 | : : : | 0.1 A********.........................****A | A**********A********A**** ++ 0.5 0.05 ++...................................++ B########B##########+ ####B########B 0 ++-------+----------B####----+-------++ 0 208 432 729 960 1200 Frequency [MHz]
- Power Model On Hikey:
According to before we have discussed for power model, i think below is the prefered power data for Hikey which calculated from raw power date:
static struct idle_state idle_states_cluster_a53[] = { { .power = 0 }, { .power = 0 }, };
/*
- Use (cluster_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_cluster_a53[] = { /* Power per cluster */ { .cap = 178, .power = 19, }, { .cap = 369, .power = 30, }, { .cap = 622, .power = 49, }, { .cap = 819, .power = 77, }, { .cap = 1024, .power = 121, }, };
/*
- Use (cpu_wfi - cluster_on) for every OPP, then calculate the
- average value for wfi's power data; But we can see actually
- the idle state of "WFI" will be impacted by voltage.
*/ static struct idle_state idle_states_core_a53[] = { { .power = 12 }, { .power = 0 }, };
/*
- Use (cpu_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_core_a53[] = { /* Power per cpu */ { .cap = 178, .power = 69, }, /* 208MHz */ { .cap = 369, .power = 125, }, /* 432MHz */ { .cap = 622, .power = 206, }, /* 729MHz */ { .cap = 819, .power = 320, }, /* 960MHz */ { .cap = 1024, .power = 502, }, /* 1.2GHz */ };
If have any questions or issues for upper energy model data, please let me know; Appreciate review and comments in advance.
Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
Please continue to use EASv5 since we're still testing EASv5.1 (including SchedDvfs) on Juno board.
BTW, the issues you and Steve M. raised against 22/46 and 32/46 of RFCv5 seen on the Hikey board (SMP) haven't been addressed in RFCv5.1 yet.
Once we get the right results for the RFCv5 test cases on Juno for EASv5.1 (including SchedDvfs) we will share it on linux-arm.org.
Thanks for suggestion.
I've pushed EASv5.1 (including SchedDfvs and rebased to current /tip/sched/core (Linux 4.3-rc5)) to:
git://linux-arm.org/linux-power.git energy_model_rfc_v5.1
The problem I saw on JUNO board (too much packing on one cpu forcing the system into over-utilized state which then spread the tasks among the little cpus and this process repeating itself over and over again leading to bad performance numbers was down to CONFIG_SCHED_AUTOGROUP=y). So make sure it's not enabled.
Acutally i have took some time to port EASv5.1 patches on my own branch, it's quite smooth to apply these patches. And i tried to port Juri and Mike's patches for SchedDVFS, there have several conflicts need to manually fix based on EASv5.1.
Anyway, i will go back to use EASv5 for power profiling. Suppose i can get some profiling result and send out for review in next 1~2 weeks :)
The way we present indexes into the 'struct idle_state' vectors has changed between 5 and 5.1. have a look into the JUNO energy model and static int group_idle_state(struct sched_group *sg).
Cheers,
-- Dietmar
Thanks, Leo Yan
-- Dietmar
i downloaded the git repo: git://www.linux-arm.org/linux-power.git, branch energy_model_rfc_v5.1; but there have no sched-dvfs related patches.
Thanks, Leo Yan