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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 09 Jan 2024 17:24:26 +0100
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Pierre Gondois <pierre.gondois@....com>, linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
 Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, Daniel Bristot de Oliveira <bristot@...hat.com>,
 Valentin Schneider <vschneid@...hat.com>, Thomas Gleixner
 <tglx@...utronix.de>
Subject: Re: [PATCH] sched/idle: Prevent stopping the tick when there is no
 cpuidle driver

Hello Pierre,

Pierre Gondois <pierre.gondois@....com> writes:

> Hello Anna-Maria,
>
> On 12/15/23 14:05, Anna-Maria Behnsen wrote:
>> When there is no cpuidle driver, the system tries to stop the tick even if
>> the system is fully loaded. But stopping the tick is not for free and it
>> decreases performance on a fully loaded system. As there is no (cpuidle)
>> framework which brings CPU in a power saving state when nothing needs to be
>> done, there is also no power saving benefit when stopping the tick.
>
> Just in case is wasn't taken into consideration:
> -
> Stopping the tick isn't free on a busy system, but it should also cost
> something to regularly handle ticks on each CPU of an idle system.
>
> FWIU, disabling the ticks also allows to add a CPU to the 'nohz.idle_cpus_mask'
> mask, which helps the idle load balancer picking an idle CPU to do load
> balancing for all the idle CPUs (cf. kick_ilb()).
>
> It seems better to do one periodic balancing for all the idle CPUs rather
> than periodically waking-up all CPUs to try to balance.
>
> -
> I would have assumed that if the system was fully loaded, ticks would
> not be stopped, or maybe I misunderstood the case.
> I assume the wake-up latency would be improved if the tick doesn't
> have to be re-setup again.
>

Your answer confuses me a little...

When there is a cpuidle driver, trying to stop the tick is not done
unconditionally. It is only done when the CPU is in a state that it
could go into a deeper C sleep - this is decided by cpuidle
driver/governor.

When there is no cpuidle driver, there is no instance which could bring
the CPU into a deeper C state. But at the moment the code does
unconditionally try to stop the tick. So the aim of the patch is to
remove this unconditional stop of the tick.

And NOHZ is independant on the cpuidle infrastructure. But when there is
no cpuidle driver, it doesn't makes sense to use then also NOHZ.

Thanks,

	Anna-Maria