| Message ID | 20190128165522.31749-7-quentin.perret@arm.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | Register an Energy Model for Arm reference platforms | expand |
On Mon, Jan 28, 2019 at 04:55:21PM +0000, Quentin Perret wrote: > From: Dietmar Eggemann <dietmar.eggemann@arm.com> > > A CPUfreq driver, like the scpi driver used on Juno boards, which > provide the Energy Model with power cost information via the PM_OPP > of_dev_pm_opp_get_cpu_power() function, do need the > dynamic-power-coefficient (C) in the device tree. > > Method used to obtain the C value: > C is computed by measuring energy (E) consumption of a frequency domain > (FD) over a 10s runtime (t) sysbench workload running at each Operating > Performance Point (OPP) affine to 1 or 2 CPUs of that FD while the other > CPUs of the system are hotplugged out. > By definition all CPUs of a FD have the the same micro-architecture. An > OPP is characterized by a certain frequency (f) and voltage (V) value. > The corresponding power values (P) are calculated by dividing the delta > of the E values between the runs with 2 and 1 CPUs by t. > > With n data tuples (P, f, V), n equal to number of OPPs for this > frequency domain, we can solve C by: > > P = Pstat + Pdyn > > P = Pstat + CV²f > > Cx = (Px - P1)/(Vx²fx - V1²f1) with x = {2, ..., n} > > The C value is the arithmetic mean out of {C2, ..., Cn}. > > Since DVFS is broken on Juno r1, no dynamic-power-coefficient > information has been added to its dts file. > Since the binding for "dynamic-power-coefficient" property already exist, and I don't see any dependency for this and the next patch(TC2) on this series, I will apply them. Please shout if for any reason that's not true. -- Regards, Sudeep
On Tuesday 29 Jan 2019 at 15:27:35 (+0000), Sudeep Holla wrote: > On Mon, Jan 28, 2019 at 04:55:21PM +0000, Quentin Perret wrote: > > From: Dietmar Eggemann <dietmar.eggemann@arm.com> > > > > A CPUfreq driver, like the scpi driver used on Juno boards, which > > provide the Energy Model with power cost information via the PM_OPP > > of_dev_pm_opp_get_cpu_power() function, do need the > > dynamic-power-coefficient (C) in the device tree. > > > > Method used to obtain the C value: > > C is computed by measuring energy (E) consumption of a frequency domain > > (FD) over a 10s runtime (t) sysbench workload running at each Operating > > Performance Point (OPP) affine to 1 or 2 CPUs of that FD while the other > > CPUs of the system are hotplugged out. > > By definition all CPUs of a FD have the the same micro-architecture. An > > OPP is characterized by a certain frequency (f) and voltage (V) value. > > The corresponding power values (P) are calculated by dividing the delta > > of the E values between the runs with 2 and 1 CPUs by t. > > > > With n data tuples (P, f, V), n equal to number of OPPs for this > > frequency domain, we can solve C by: > > > > P = Pstat + Pdyn > > > > P = Pstat + CV²f > > > > Cx = (Px - P1)/(Vx²fx - V1²f1) with x = {2, ..., n} > > > > The C value is the arithmetic mean out of {C2, ..., Cn}. > > > > Since DVFS is broken on Juno r1, no dynamic-power-coefficient > > information has been added to its dts file. > > > > Since the binding for "dynamic-power-coefficient" property already exist, > and I don't see any dependency for this and the next patch(TC2) on this > series, I will apply them. Please shout if for any reason that's not true. Thanks Sudeep ! Quentin
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts index ab77adb4f3c2..66f0ec79c864 100644 --- a/arch/arm64/boot/dts/arm/juno-r2.dts +++ b/arch/arm64/boot/dts/arm/juno-r2.dts @@ -99,6 +99,7 @@ clocks = <&scpi_dvfs 0>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <1024>; + dynamic-power-coefficient = <450>; }; A72_1: cpu@1 { @@ -116,6 +117,7 @@ clocks = <&scpi_dvfs 0>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <1024>; + dynamic-power-coefficient = <450>; }; A53_0: cpu@100 { @@ -133,6 +135,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <485>; + dynamic-power-coefficient = <140>; }; A53_1: cpu@101 { @@ -150,6 +153,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <485>; + dynamic-power-coefficient = <140>; }; A53_2: cpu@102 { @@ -167,6 +171,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <485>; + dynamic-power-coefficient = <140>; }; A53_3: cpu@103 { @@ -184,6 +189,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <485>; + dynamic-power-coefficient = <140>; }; A72_L2: l2-cache0 { diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts index 08d4ba1716c3..9890afdda77b 100644 --- a/arch/arm64/boot/dts/arm/juno.dts +++ b/arch/arm64/boot/dts/arm/juno.dts @@ -98,6 +98,7 @@ clocks = <&scpi_dvfs 0>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <1024>; + dynamic-power-coefficient = <530>; }; A57_1: cpu@1 { @@ -115,6 +116,7 @@ clocks = <&scpi_dvfs 0>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <1024>; + dynamic-power-coefficient = <530>; }; A53_0: cpu@100 { @@ -132,6 +134,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <578>; + dynamic-power-coefficient = <140>; }; A53_1: cpu@101 { @@ -149,6 +152,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <578>; + dynamic-power-coefficient = <140>; }; A53_2: cpu@102 { @@ -166,6 +170,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <578>; + dynamic-power-coefficient = <140>; }; A53_3: cpu@103 { @@ -183,6 +188,7 @@ clocks = <&scpi_dvfs 1>; cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; capacity-dmips-mhz = <578>; + dynamic-power-coefficient = <140>; }; A57_L2: l2-cache0 {