| Message ID | 20190328101352.25657-2-quentin.perret@arm.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | cpu_cooling: Make IPA use PM_EM | expand |
On Thursday 28 Mar 2019 at 10:13:50 (+0000), Quentin Perret wrote: > The recently introduced Energy Model (EM) framework manages power cost > tables for the CPUs of the system. Its only user right now is the > scheduler, in the context of Energy Aware Scheduling (EAS). > > However, the EM framework also offers a generic infrastructure that > could replace subsystem-specific implementations of the same concepts, > as this is the case in the thermal framework. > > So, in order to prepare the migration of the thermal subsystem to use > the EM framework, enable it in the default arm64 defconfig, which is the > most commonly used architecture for IPA. This will also compile-in all > of the EAS code, although it won't be enabled by default -- EAS requires > to use the 'schedutil' CPUFreq governor while arm64 defaults to > 'performance'. > > Signed-off-by: Quentin Perret <quentin.perret@arm.com> > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 2d9c39033c1a..3c09bdaaefd3 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -97,6 +97,7 @@ CONFIG_XEN=y > CONFIG_COMPAT=y > CONFIG_HIBERNATION=y > CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y > +CONFIG_ENERGY_MODEL=n Hmm, sorry I turned this to '=n' for testing and forgot to update the patch. This obviously should be '=y' ... > CONFIG_ARM_CPUIDLE=y > CONFIG_CPU_FREQ=y > CONFIG_CPU_FREQ_STAT=y > -- > 2.21.0 >
On 28/03/2019 11:22, Quentin Perret wrote: > On Thursday 28 Mar 2019 at 10:13:50 (+0000), Quentin Perret wrote: >> The recently introduced Energy Model (EM) framework manages power cost >> tables for the CPUs of the system. Its only user right now is the >> scheduler, in the context of Energy Aware Scheduling (EAS). >> >> However, the EM framework also offers a generic infrastructure that >> could replace subsystem-specific implementations of the same concepts, >> as this is the case in the thermal framework. >> >> So, in order to prepare the migration of the thermal subsystem to use >> the EM framework, enable it in the default arm64 defconfig, which is the >> most commonly used architecture for IPA. This will also compile-in all >> of the EAS code, although it won't be enabled by default -- EAS requires >> to use the 'schedutil' CPUFreq governor while arm64 defaults to >> 'performance'. >> >> Signed-off-by: Quentin Perret <quentin.perret@arm.com> >> --- >> arch/arm64/configs/defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >> index 2d9c39033c1a..3c09bdaaefd3 100644 >> --- a/arch/arm64/configs/defconfig >> +++ b/arch/arm64/configs/defconfig >> @@ -97,6 +97,7 @@ CONFIG_XEN=y >> CONFIG_COMPAT=y >> CONFIG_HIBERNATION=y >> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y >> +CONFIG_ENERGY_MODEL=n > > Hmm, sorry I turned this to '=n' for testing and forgot to update the > patch. This obviously should be '=y' ... I did a test without the ENERGY_MODEL config option set, dhrystone and the power_allocator policy on the hikey. The board did not mitigate well and ended up rebooting. May be the cpu cooling Kconfig option should add a SELECT or a DEPENDS on ENERGY_MODEL ? >> CONFIG_ARM_CPUIDLE=y >> CONFIG_CPU_FREQ=y >> CONFIG_CPU_FREQ_STAT=y >> -- >> 2.21.0 >>
Hi Daniel, On Thursday 28 Mar 2019 at 18:27:49 (+0100), Daniel Lezcano wrote: > On 28/03/2019 11:22, Quentin Perret wrote: > >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > >> index 2d9c39033c1a..3c09bdaaefd3 100644 > >> --- a/arch/arm64/configs/defconfig > >> +++ b/arch/arm64/configs/defconfig > >> @@ -97,6 +97,7 @@ CONFIG_XEN=y > >> CONFIG_COMPAT=y > >> CONFIG_HIBERNATION=y > >> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y > >> +CONFIG_ENERGY_MODEL=n > > > > Hmm, sorry I turned this to '=n' for testing and forgot to update the > > patch. This obviously should be '=y' ... > > I did a test without the ENERGY_MODEL config option set, dhrystone and > the power_allocator policy on the hikey. The board did not mitigate well > and ended up rebooting. OK ... And is the same thing happening if you just run mainline w/o the dynamic-power-coefficient binding set for example ? The result _should_ be the same. If not, then perhaps I missed something. I'll try to reproduce on my end. Just to be sure, when you say hikey, you mean hikey960 ? Or 620 ? In any case, thanks for testing :-) > May be the cpu cooling Kconfig option should add > a SELECT or a DEPENDS on ENERGY_MODEL ? Right, I've been wondering the same thing. I'm not a big fan of 'select' because enabling ENERGY_MODEL automatically for the thermal stuff will also happen to enable other things (EAS) without the user knowing. So I'd rather keep the ENERGY_MODEL option explicit. But perhaps having THERMAL_GOV_POWER_ALLOCATOR 'depend on ENERGY_MODEL' could work. It's just that there is no _strong_ dependency, the IPA code isn't supposed to crash even if there is no EM ... Thanks, Quentin
On 28/03/2019 18:42, Quentin Perret wrote: > Hi Daniel, > > On Thursday 28 Mar 2019 at 18:27:49 (+0100), Daniel Lezcano wrote: >> On 28/03/2019 11:22, Quentin Perret wrote: >>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >>>> index 2d9c39033c1a..3c09bdaaefd3 100644 >>>> --- a/arch/arm64/configs/defconfig >>>> +++ b/arch/arm64/configs/defconfig >>>> @@ -97,6 +97,7 @@ CONFIG_XEN=y >>>> CONFIG_COMPAT=y >>>> CONFIG_HIBERNATION=y >>>> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y >>>> +CONFIG_ENERGY_MODEL=n >>> >>> Hmm, sorry I turned this to '=n' for testing and forgot to update the >>> patch. This obviously should be '=y' ... >> >> I did a test without the ENERGY_MODEL config option set, dhrystone and >> the power_allocator policy on the hikey. The board did not mitigate well >> and ended up rebooting. > > OK ... And is the same thing happening if you just run mainline w/o the > dynamic-power-coefficient binding set for example ? The result _should_ > be the same. Right, it is the same. > If not, then perhaps I missed something. I'll try to > reproduce on my end. Just to be sure, when you say hikey, you mean > hikey960 ? Or 620 ? In any case, thanks for testing :-) hikey620 >> May be the cpu cooling Kconfig option should add >> a SELECT or a DEPENDS on ENERGY_MODEL ? > > Right, I've been wondering the same thing. I'm not a big fan of 'select' > because enabling ENERGY_MODEL automatically for the thermal stuff will > also happen to enable other things (EAS) without the user knowing. So > I'd rather keep the ENERGY_MODEL option explicit. > > But perhaps having THERMAL_GOV_POWER_ALLOCATOR 'depend on ENERGY_MODEL' > could work. It's just that there is no _strong_ dependency, the IPA code > isn't supposed to crash even if there is no EM ... Given if the ENERGY_MODEL is not set there is a regression we should add the dependency IMO.
On Thursday 28 Mar 2019 at 20:51:12 (+0100), Daniel Lezcano wrote: > On 28/03/2019 18:42, Quentin Perret wrote: > > Hi Daniel, > > > > On Thursday 28 Mar 2019 at 18:27:49 (+0100), Daniel Lezcano wrote: > >> On 28/03/2019 11:22, Quentin Perret wrote: > >>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > >>>> index 2d9c39033c1a..3c09bdaaefd3 100644 > >>>> --- a/arch/arm64/configs/defconfig > >>>> +++ b/arch/arm64/configs/defconfig > >>>> @@ -97,6 +97,7 @@ CONFIG_XEN=y > >>>> CONFIG_COMPAT=y > >>>> CONFIG_HIBERNATION=y > >>>> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y > >>>> +CONFIG_ENERGY_MODEL=n > >>> > >>> Hmm, sorry I turned this to '=n' for testing and forgot to update the > >>> patch. This obviously should be '=y' ... > >> > >> I did a test without the ENERGY_MODEL config option set, dhrystone and > >> the power_allocator policy on the hikey. The board did not mitigate well > >> and ended up rebooting. > > > > OK ... And is the same thing happening if you just run mainline w/o the > > dynamic-power-coefficient binding set for example ? The result _should_ > > be the same. > > Right, it is the same. OK. > > > If not, then perhaps I missed something. I'll try to > > reproduce on my end. Just to be sure, when you say hikey, you mean > > hikey960 ? Or 620 ? In any case, thanks for testing :-) > > hikey620 > > >> May be the cpu cooling Kconfig option should add > >> a SELECT or a DEPENDS on ENERGY_MODEL ? > > > > Right, I've been wondering the same thing. I'm not a big fan of 'select' > > because enabling ENERGY_MODEL automatically for the thermal stuff will > > also happen to enable other things (EAS) without the user knowing. So > > I'd rather keep the ENERGY_MODEL option explicit. > > > > But perhaps having THERMAL_GOV_POWER_ALLOCATOR 'depend on ENERGY_MODEL' > > could work. It's just that there is no _strong_ dependency, the IPA code > > isn't supposed to crash even if there is no EM ... > > Given if the ENERGY_MODEL is not set there is a regression we should add > the dependency IMO. Right, that is true. And there are folks who don't use the arm64 defconfig downstream, so I guess we need to make it clear for them they need to enable ENERGY_MODEL from now on. I'll add a 'depends on ENERGY_MODEL' to 'THERMAL_GOV_POWER_ALLOCATOR' in patch 3 for v2. Thanks, Quentin
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2d9c39033c1a..3c09bdaaefd3 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -97,6 +97,7 @@ CONFIG_XEN=y CONFIG_COMPAT=y CONFIG_HIBERNATION=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y +CONFIG_ENERGY_MODEL=n CONFIG_ARM_CPUIDLE=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_STAT=y
The recently introduced Energy Model (EM) framework manages power cost tables for the CPUs of the system. Its only user right now is the scheduler, in the context of Energy Aware Scheduling (EAS). However, the EM framework also offers a generic infrastructure that could replace subsystem-specific implementations of the same concepts, as this is the case in the thermal framework. So, in order to prepare the migration of the thermal subsystem to use the EM framework, enable it in the default arm64 defconfig, which is the most commonly used architecture for IPA. This will also compile-in all of the EAS code, although it won't be enabled by default -- EAS requires to use the 'schedutil' CPUFreq governor while arm64 defaults to 'performance'. Signed-off-by: Quentin Perret <quentin.perret@arm.com> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)