diff mbox series

[1/3] arm64: defconfig: Enable CONFIG_ENERGY_MODEL

Message ID 20190328101352.25657-2-quentin.perret@arm.com (mailing list archive)
State New, archived
Headers show
Series cpu_cooling: Make IPA use PM_EM | expand

Commit Message

Quentin Perret March 28, 2019, 10:13 a.m. UTC
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(+)

Comments

Quentin Perret March 28, 2019, 10:22 a.m. UTC | #1
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
>
Daniel Lezcano March 28, 2019, 5:27 p.m. UTC | #2
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
>>
Quentin Perret March 28, 2019, 5:42 p.m. UTC | #3
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
Daniel Lezcano March 28, 2019, 7:51 p.m. UTC | #4
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.
Quentin Perret March 29, 2019, 9:03 a.m. UTC | #5
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 mbox series

Patch

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