linux-kernel - Re: [PATCH V6 1/3] cpuidle: play_idle: Make play

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, 08 Nov 2019 01:53:25 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     mathieu.poirier@...aro.org, mingo@...hat.com, peterz@...radead.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        ulf.hansson@...aro.org
Subject: Re: [PATCH V6 1/3] cpuidle: play_idle: Make play_idle more flexible

On Wednesday, November 6, 2019 7:27:47 PM CET Daniel Lezcano wrote:
> 
> Hi Rafael,
> 
> 
> On 30/10/2019 08:51, Daniel Lezcano wrote:
> > The play_idle function has two users, the intel powerclamp and the
> > idle_injection.
> > 
> > The idle injection cooling device uses the function via the
> > idle_injection powercap's APIs. Unfortunately, play_idle is currently
> > limited by the idle state depth: by default the deepest idle state is
> > selected. On the ARM[64] platforms, most of the time it is the cluster
> > idle state, the exit latency and the residency can be very high. That
> > reduces the scope of the idle injection usage because the impact on
> > the performances can be very significant.
> > 
> > If the idle injection cycles can be done with a shallow state like a
> > retention state, the cooling effect would eventually give similar
> > results than the cpufreq cooling device.
> > 
> > In order to prepare the function to receive an idle state parameter,
> > let's replace the 'use_deepest_state' boolean field with 'use_state'
> > and use this value to enter the specific idle state.
> > 
> > The current code keeps the default behavior which is go to the deepest
> > idle state.
> > 
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
> > Acked-by: Mathieu Poirier <mathieu.poirier@...aro.org>
> > Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
> 
> Is it possible to merge this series so I can make some progress on
> upstreaming the idle cooling device which depends on these three patches?

That would be possible if the series had no problems, but it appears to have
some.

Let me reply to the patches.