linux-kernel - Re: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs

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:   Thu, 9 Aug 2018 11:25:04 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Lina Iyer <ilina@...eaurora.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Sudeep Holla <sudeep.holla@....com>,
        Mark Rutland <mark.rutland@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Juri Lelli <juri.lelli@....com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle
 path for CPUs

On Wed, Aug 08, 2018 at 12:02:48PM -0600, Lina Iyer wrote:
> On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote:
> >On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:
> >>On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> >>> [...]
> >>>
> >>>>>
> >>>>> Assuming that I have got that right, there are concerns, mostly regarding
> >>>>> patch [07/26], but I will reply to that directly.
> >>>>
> >>>> Well, I haven't got that right, so never mind.
> >>>>
> >>>> There are a few minor things to address, but apart from that the general
> >>>> genpd patches look ready.
> >>>
> >>> Alright, thanks!
> >>>
> >>> I will re-spin the series and post a new version once 4.19 rc1 is out.
> >>> Hopefully we can queue it up early in next cycle to get it tested in
> >>> next for a while.
> >>>
> >>>>
> >>>>> The $subject patch is fine by me by itself, but it obviously depends on the
> >>>>> previous ones.  Patches [01-02/26] are fine too, but they don't seem to be
> >>>>> particularly useful without the rest of the series.
> >>>>>
> >>>>> As far as patches [10-26/26] go, I'd like to see some review comments and/or
> >>>>> tags from the people with vested interest in there, in particular from Daniel
> >>>>> on patch [12/26] and from Sudeep on the PSCI ones.
> >>>>
> >>>> But this still holds.
> >>>
> >>> Actually, patch 10 and patch11 is ready to go as well. I ping Daniel
> >>> on patch 12.
> >>>
> >>> In regards to the rest of the series, some of the PSCI/ARM changes
> >>> have been reviewed by Mark Rutland, however several changes have not
> >>> been acked.
> >>>
> >>> On the other hand, one can also interpret the long silence in regards
> >>> to PSCI/ARM changes as they are good to go. :-)
> >>
> >>Well, in that case giving an ACK to them should not be an issue for
> >>the people with a vested interest I suppose.
> >
> >Apologies to everyone for the delay in replying.
> >
> >Side note: cpu_pm_enter()/exit() are also called through syscore ops in
> >s2RAM/IDLE, you know that but I just wanted to mention it to compound
> >the discussion.
> >
> >As for PSCI patches I do not personally think PSCI OSI enablement is
> >beneficial (and my position has always been the same since PSCI OSI was
> >added to the specification, I am not even talking about this patchset)
> >and Arm Trusted Firmware does not currently support it for the same
> >reason.
> >
> >We (if Mark and Sudeep agree) will enable PSCI OSI if and when we have a
> >definitive and constructive answer to *why* we have to do that that is
> >not a dogmatic "the kernel knows better" but rather a comprehensive
> >power benchmark evaluation - I thought that was the agreement reached
> >at OSPM but apparently I was mistaken.
> >
> I will not speak to any comparison of benchmarks between OSI and PC.
> AFAIK, there are no platforms supporting both.

PSCI specifications, 5.20.1:

"The platform will boot in platform-coordinated mode."

So all platforms implementing OSI have to support both.

> But, the OSI feature is critical for QCOM mobile platforms. The
> last man activities during cpuidle save quite a lot of power.

What I expressed above was that, in PSCI based systems (OSI or PC
alike), it is up to firmware/hardware to detect "the last man" not
the kernel.

I need to understand what you mean by "last man activities" to
provide feedback here.

> Powering off the clocks, busses, regulators and even the oscillator is
> very important to have a reasonable battery life when using the phone.
> Platform coordinated approach falls quite short of the needs of a
> powerful processor with a desired battery efficiency.

I am sorry but if you want us to merge PSCI patches in this series you
will have to back the claim above with a detailed technical explanation
of *why* platform-coordination falls short of QCOM (or whoever else)
needs wrt PSCI OSI.

Thanks,
Lorenzo