From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lorenzo Pieralisi Subject: Re: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs Date: Thu, 9 Aug 2018 11:25:04 +0100 Message-ID: <20180809102504.GB13428@e107981-ln.cambridge.arm.com> References: <20180620172226.15012-1-ulf.hansson@linaro.org> <2056372.NMt4aPaF4h@aspire.rjw.lan> <2205807.cU2puvubpP@aspire.rjw.lan> <1726374.375PCQfjLZ@aspire.rjw.lan> <20180808105619.GB25150@e107981-ln.cambridge.arm.com> <20180808180248.GC27850@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20180808180248.GC27850@codeaurora.org> Sender: linux-kernel-owner@vger.kernel.org To: Lina Iyer Cc: "Rafael J. Wysocki" , Ulf Hansson , "Rafael J. Wysocki" , Sudeep Holla , Mark Rutland , Linux PM , Kevin Hilman , Lina Iyer , Rob Herring , Daniel Lezcano , Thomas Gleixner , Vincent Guittot , Stephen Boyd , Juri Lelli , Geert Uytterhoeven , Linux ARM , linux-arm-msm , Linux Kernel Mailing List List-Id: linux-arm-msm@vger.kernel.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi) Date: Thu, 9 Aug 2018 11:25:04 +0100 Subject: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs In-Reply-To: <20180808180248.GC27850@codeaurora.org> References: <20180620172226.15012-1-ulf.hansson@linaro.org> <2056372.NMt4aPaF4h@aspire.rjw.lan> <2205807.cU2puvubpP@aspire.rjw.lan> <1726374.375PCQfjLZ@aspire.rjw.lan> <20180808105619.GB25150@e107981-ln.cambridge.arm.com> <20180808180248.GC27850@codeaurora.org> Message-ID: <20180809102504.GB13428@e107981-ln.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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