diff mbox series

arm64: defconfig: Select schedutil as default cpufreq governor

Message ID af12e002bc165844101830c0eb00e283b536a879.1510813288.git.viresh.kumar@linaro.org
State New
Headers show
Series arm64: defconfig: Select schedutil as default cpufreq governor | expand

Commit Message

Viresh Kumar Nov. 16, 2017, 6:21 a.m. UTC
Currently performance governor is getting selected by default, which is
surely not a very good choice as its pretty much power hungry.

Select schedutil instead.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
2.15.0.194.g9af6a3dea062

Comments

Viresh Kumar Dec. 15, 2017, 10:45 a.m. UTC | #1
On 16-11-17, 11:51, Viresh Kumar wrote:
> Currently performance governor is getting selected by default, which is

> surely not a very good choice as its pretty much power hungry.

> 

> Select schedutil instead.

> 

> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

> ---

>  arch/arm64/configs/defconfig | 1 +

>  1 file changed, 1 insertion(+)

> 

> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig

> index 34480e9af2e7..9424a7aafdb2 100644

> --- a/arch/arm64/configs/defconfig

> +++ b/arch/arm64/configs/defconfig

> @@ -93,6 +93,7 @@ CONFIG_HIBERNATION=y

>  CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y

>  CONFIG_ARM_CPUIDLE=y

>  CONFIG_CPU_FREQ=y

> +CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y

>  CONFIG_CPUFREQ_DT=y

>  CONFIG_ARM_BIG_LITTLE_CPUFREQ=y

>  CONFIG_ARM_SCPI_CPUFREQ=y


Ping !!

-- 
viresh
Catalin Marinas Dec. 15, 2017, 3:50 p.m. UTC | #2
On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:
> Currently performance governor is getting selected by default, which is

> surely not a very good choice as its pretty much power hungry.

> 

> Select schedutil instead.


And why do we care about this in defconfig? People deploying their own
kernels in mobile may opt for this config, others may prefer the default
governor.

Also it seems it would be the only architecture make this governor the
default, so NAK.

-- 
Catalin
Viresh Kumar Dec. 18, 2017, 4:29 a.m. UTC | #3
On 15-12-17, 15:50, Catalin Marinas wrote:
> On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:

> > Currently performance governor is getting selected by default, which is

> > surely not a very good choice as its pretty much power hungry.

> > 

> > Select schedutil instead.

> 

> And why do we care about this in defconfig? People deploying their own

> kernels in mobile may opt for this config, others may prefer the default

> governor.

> 

> Also it seems it would be the only architecture make this governor the

> default, so NAK.


This is a bit dangerous configuration IMHO.

Other architectures have some *real* governor selected by default, like Ondemand
or Conservative. Running your CPUs at max (because of the default performance
governor in arm64 config) may end up burning some SoCs accidentally just because
their thermal stuff doesn't kick in to cool SoC down properly.

So, we should have one of ondemand, conservative and schedutil selected by
default for arm64 as well IMO and schedutil is the one which every one is
falling back to now a days, even android.

-- 
viresh
Marc Zyngier Dec. 19, 2017, 6:30 p.m. UTC | #4
On 18/12/17 04:29, Viresh Kumar wrote:
> On 15-12-17, 15:50, Catalin Marinas wrote:

>> On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:

>>> Currently performance governor is getting selected by default, which is

>>> surely not a very good choice as its pretty much power hungry.

>>>

>>> Select schedutil instead.

>>

>> And why do we care about this in defconfig? People deploying their own

>> kernels in mobile may opt for this config, others may prefer the default

>> governor.

>>

>> Also it seems it would be the only architecture make this governor the

>> default, so NAK.

> 

> This is a bit dangerous configuration IMHO.

> 

> Other architectures have some *real* governor selected by default, like Ondemand

> or Conservative. Running your CPUs at max (because of the default performance

> governor in arm64 config) may end up burning some SoCs accidentally just because

> their thermal stuff doesn't kick in to cool SoC down properly.


Honestly, this feels like widening a road because someone wants to drive
a car with no steering wheel. If an SoC is broken enough not to to into
thermal throttling on its own, I'm tempted to say "let it burn".

And on-demand is just as bad as performance in that respect, as it will
to the same thing as soon as you run (for example) Firefox. Or Emacs.

> So, we should have one of ondemand, conservative and schedutil selected by

> default for arm64 as well IMO and schedutil is the one which every one is

> falling back to now a days, even android.


I'll have my bike shed painted pink, thank you very much! :-)

	M.
-- 
Jazz is not dead. It just smells funny...
Arnd Bergmann Dec. 21, 2017, 3:32 p.m. UTC | #5
On Mon, Dec 18, 2017 at 5:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 15-12-17, 15:50, Catalin Marinas wrote:

>> On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:

>> > Currently performance governor is getting selected by default, which is

>> > surely not a very good choice as its pretty much power hungry.

>> >

>> > Select schedutil instead.

>>

>> And why do we care about this in defconfig? People deploying their own

>> kernels in mobile may opt for this config, others may prefer the default

>> governor.

>>

>> Also it seems it would be the only architecture make this governor the

>> default, so NAK.

>

> This is a bit dangerous configuration IMHO.

>

> Other architectures have some *real* governor selected by default, like Ondemand

> or Conservative. Running your CPUs at max (because of the default performance

> governor in arm64 config) may end up burning some SoCs accidentally just because

> their thermal stuff doesn't kick in to cool SoC down properly.

>

> So, we should have one of ondemand, conservative and schedutil selected by

> default for arm64 as well IMO and schedutil is the one which every one is

> falling back to now a days, even android.


Maybe it's time to change the global 'default
CPU_FREQ_DEFAULT_GOV_PERFORMANCE' instead to avoid having to
do this for each architecture separately?

I think the general idea of using schedutil or ondemand instead of performance
makes sense, but it doesn't feel right to have to do this for every
single defconfig
that doesn't select a default.

      Arnd
Viresh Kumar Dec. 22, 2017, 4:46 a.m. UTC | #6
On 21-12-17, 16:32, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 5:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:

> > On 15-12-17, 15:50, Catalin Marinas wrote:

> >> On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:

> >> > Currently performance governor is getting selected by default, which is

> >> > surely not a very good choice as its pretty much power hungry.

> >> >

> >> > Select schedutil instead.

> >>

> >> And why do we care about this in defconfig? People deploying their own

> >> kernels in mobile may opt for this config, others may prefer the default

> >> governor.

> >>

> >> Also it seems it would be the only architecture make this governor the

> >> default, so NAK.

> >

> > This is a bit dangerous configuration IMHO.

> >

> > Other architectures have some *real* governor selected by default, like Ondemand

> > or Conservative. Running your CPUs at max (because of the default performance

> > governor in arm64 config) may end up burning some SoCs accidentally just because

> > their thermal stuff doesn't kick in to cool SoC down properly.

> >

> > So, we should have one of ondemand, conservative and schedutil selected by

> > default for arm64 as well IMO and schedutil is the one which every one is

> > falling back to now a days, even android.

> 

> Maybe it's time to change the global 'default

> CPU_FREQ_DEFAULT_GOV_PERFORMANCE' instead to avoid having to

> do this for each architecture separately?

> 

> I think the general idea of using schedutil or ondemand instead of performance

> makes sense, but it doesn't feel right to have to do this for every

> single defconfig

> that doesn't select a default.


+Rafael to see what his views are on this.

-- 
viresh
diff mbox series

Patch

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 34480e9af2e7..9424a7aafdb2 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -93,6 +93,7 @@  CONFIG_HIBERNATION=y
 CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
 CONFIG_ARM_CPUIDLE=y
 CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
 CONFIG_ARM_SCPI_CPUFREQ=y