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: Fri, 12 Jan 2024 14:39:46 +0100
From: Pierre Gondois <pierre.gondois@....com>
To: Anna-Maria Behnsen <anna-maria@...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>,
 Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] sched/idle: Prevent stopping the tick when there is no
 cpuidle driver

Hello Anna-Maria,

On 1/12/24 11:56, Anna-Maria Behnsen wrote:
> Pierre Gondois <pierre.gondois@....com> writes:
> 
>> Hello Anna-Maria,
>>
>> On 1/9/24 17:24, Anna-Maria Behnsen wrote:
>>>
>>> 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.
>>
>> 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

Without patch:
|       |     big-CPUs | little-CPUs |
|:------|-------------:|------------:|
| count | 10           | 10          |
| mean  |  0.353266    |  0.33399    |
| std   |  0.000254574 |  0.00206803 |
| min   |  0.352991    |  0.332145   |
| 25%   |  0.353039    |  0.332506   |
| 50%   |  0.353267    |  0.333089   |
| 75%   |  0.353412    |  0.335231   |
| max   |  0.353737    |  0.337964   |

With patch:
|       |     big-CPUs |  little-CPUs |
|:------|-------------:|-------------:|
| count | 10           | 10           |
| mean  |  0.375086    |  0.352451    |
| std   |  0.000299919 |  0.000752727 |
| min   |  0.374527    |  0.351743    |
| 25%   |  0.374872    |  0.35181     |
| 50%   |  0.37512     |  0.352063    |
| 75%   |  0.375335    |  0.353256    |
| max   |  0.375485    |  0.353461    |

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

Regards,
Pierre


> 
> Thanks,
> 
>          Anna-Maria
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ