Re: [PATCH] sched/idle: Prevent stopping the tick when there is no cpuidle driver

From: Pierre Gondois
Date: Mon Jan 15 2024 - 10:42:25 EST




On 1/15/24 14:29, Vincent Guittot wrote:
On Mon, 15 Jan 2024 at 13:40, Pierre Gondois <pierre.gondois@xxxxxxx> wrote:

Hello Thomas,

On 1/12/24 15:52, Thomas Gleixner wrote:
On Fri, Jan 12 2024 at 14:39, Pierre Gondois wrote:
On 1/12/24 11:56, Anna-Maria Behnsen wrote:
Pierre Gondois <pierre.gondois@xxxxxxx> writes:
I agree that the absence of cpuidle driver prevents from reaching deep
idle states. FWIU, there is however still benefits in stopping the tick
on such platform.

What's the benefit?

I did the following test:
- on an arm64 Juno-r2 platform (2 big A-72 and 4 little A-53 CPUs)
- booting with 'cpuidle.off=1'
- using the energy counters of the platforms
(the counters measure energy for the whole cluster of big/little CPUs)
- letting the platform idling during 10s

So the energy consumption would be up:
- ~6% for the big CPUs
- ~10% for the litte CPUs

Fair enough, but what's the actual usecase?

NOHZ w/o cpuidle driver seems a rather academic exercise to me.

Don't know if it's really a valid use case but can't we have VMs in
such a configuration ?
NOHZ enabled and no cpuidle driver as VM doesn't manage HW anyway ?

Yes right,
I tried with a kvmtool generated VM and it seemed to be the case:

$ grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/available_governors:menu
/sys/devices/system/cpu/cpuidle/current_driver:none
/sys/devices/system/cpu/cpuidle/current_governor:menu
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu




I thought Anna-Maria had a use-case for this.
I just wanted to point out that this patch could potentially
increase the energy consumption for her use-case, nothing more,

Regards,
Pierre


Thanks,

tglx