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]

Message-ID: <877ckad9np.fsf@somnus>
Date: Mon, 15 Jan 2024 14:10:50 +0100
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Pierre Gondois <pierre.gondois@....com>, Thomas Gleixner
 <tglx@...utronix.de>, 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>
Subject: Re: [PATCH] sched/idle: Prevent stopping the tick when there is no
 cpuidle driver

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

> 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@....com> 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.
>
> 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,
>

I saw tons of calls trying to stop the tick on a loaded system - which
decreased performance. Deep sleep states were disabled (by accident) in
the BIOS but NOHZ was enabled. So my proposal is to remove this
unconditional call trying to stop the tick.

Thanks,

        Anna-Maria