From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Sudeep Holla <sudeep.holla@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Linux PM <linux-pm@vger.kernel.org>,
Kevin Hilman <khilman@kernel.org>,
Lina Iyer <ilina@codeaurora.org>,
Lina Iyer <lina.iyer@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Vincent Guittot <vincent.guittot@linaro.org>,
Stephen Boyd <sboyd@kernel.org>, Juri Lelli <juri.lelli@arm.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v8 07/26] PM / Domains: Add genpd governor for CPUs
Date: Thu, 13 Sep 2018 16:37:27 +0100 [thread overview]
Message-ID: <20180913153727.GB6199@e107981-ln.cambridge.arm.com> (raw)
In-Reply-To: <CAPDyKFqDHeMwyJ3Xx1kJcj968s=__3juR5bPn-d_3w=bzo-ovA@mail.gmail.com>
On Thu, Aug 30, 2018 at 03:36:02PM +0200, Ulf Hansson wrote:
> On 24 August 2018 at 12:38, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> > On Fri, Aug 24, 2018 at 11:26:19AM +0200, Ulf Hansson wrote:
> >
> > [...]
> >
> >> > That's a good question and it maybe gives a path towards a solution.
> >> >
> >> > AFAICS the genPD governor only selects the idle state parameter that
> >> > determines the idle state at, say, GenPD cpumask level it does not touch
> >> > the CPUidle decision, that works on a subset of idle states (at cpu
> >> > level).
> >> >
> >> > That's my understanding, which can be wrong so please correct me
> >> > if that's the case because that's a bit confusing.
> >> >
> >> > Let's imagine that we flattened out the list of idle states and feed
> >> > CPUidle with it (all of them - cpu, cluster, package, system - as it is
> >> > in the mainline _now_). Then the GenPD governor can run-through the
> >> > CPUidle selection and _demote_ the idle state if necessary since it
> >> > understands that some CPUs in the GenPD will wake up shortly and break
> >> > the target residency hyphothesis the CPUidle governor is expecting.
> >> >
> >> > The whole idea about this series is improving CPUidle decision when
> >> > the target idle state is _shared_ among groups of cpus (again, please
> >> > do correct me if I am wrong).
> >>
> >> Absolutely, this is one of the main reason for the series!
> >>
> >> >
> >> > It is obvious that a GenPD governor must only demote - never promote a
> >> > CPU idle state selection given that hierarchy implies more power
> >> > savings and higher target residencies required.
> >>
> >> Absolutely. I apologize if I have been using the word "promote"
> >> wrongly, I realize it may be a bit confusing.
> >>
> >> >
> >> > This whole series would become more generic and won't depend on
> >> > PSCI OSI at all - actually that would become a hierarchical
> >> > CPUidle governor.
> >>
> >> Well, to me we need a first user of the new infrastructure code in
> >> genpd and PSCI is probably the easiest one to start with. An option
> >> would be to start with an old ARM32 platform, but it seems a bit silly
> >> to me.
> >
> > If the code can be structured as described above as a hierarchical
> > (possibly optional through a Kconfig entry or sysfs tuning) idle
> > decision you can apply it to _any_ PSCI based platform out there,
> > provided that the new governor improves power savings.
> >
> >> In regards to OS-initiated mode vs platform coordinated mode, let's
> >> discuss that in details in the other email thread instead.
> >
> > I think that's crystal clear by now that IMHO PSCI OS-initiated mode is
> > a red-herring, it has nothing to do with this series, it is there just
> > because QC firmware does not support PSCI platform coordinated suspend
> > mode.
>
> I fully agree that the series isn't specific to PSCI OSI mode. On the
> other hand, for PSCI OSI mode, that's where I see this series to fit
> naturally. And in particular for the QCOM 410c board.
>
> When it comes to the PSCI PC mode, it may under certain circumstances
> be useful to deploy this approach for that as well, and I agree that
> it seems reasonable to have that configurable as opt-in, somehow.
>
> Although, let's discuss that separately, in a next step. Or at least
> let's try to keep PSCI related technical discussions to the other
> thread, as that makes it easier to follow.
>
> >
> > You can apply the concept in this series to _any_ arch provided
> > the power domains representation is correct (and again, I would sound
> > like a broken record but the series must improve power savings over
> > vanilla CPUidle menu governor).
>
> I agree, but let me elaborate a bit, to hopefully add some clarity,
> which I may not have been able to communicate earlier.
>
> The goal with the series is to enable platforms to support all its
> available idlestates, which are shared among a group of CPUs. This is
> the case for QCOM 410c, for example.
>
> To my knowledge, we have other ARM32 based platforms that currently
> have disabled some of its cluster idle states. That's because they
> can't know when it's safe to power off the cluster "coherency domain",
> in cases when the platform also have other shared resources in it.
>
> The point is, to see improved power savings, additional platform
> deployment may be needed and that just takes time. For example runtime
> PM support is needed in those drivers that deals with the "shared
> resources", a correctly modeled PM domain topology using genpd, etc,
> etc.
>
> >
> >> > I still think that PSCI firmware and most certainly mwait() play the
> >> > role the GenPD governor does since they can detect in FW/HW whether
> >> > that's worthwhile to switch off a domain, the information is obviously
> >> > there and the kernel would just add latency to the idle path in that
> >> > case but let's gloss over this for the sake of this discussion.
> >>
> >> Yep, let's discuss that separately.
> >>
> >> That said, can I interpret your comments on the series up until this
> >> change, that you seems rather happy with where the series is going?
> >
> > It is something we have been discussing with Daniel since generic idle
> > was merged for Arm a long while back. I have nothing against describing
> > idle states with power domains but it must improve idle decisions
> > against the mainline. As I said before, runtime PM can also be used
> > to get rid of CPU PM notifiers (because with power domains we KNOW
> > what devices eg PMU are switched off on idle entry, we do not guess
> > any longer; replacing CPU PM notifiers is challenging and can be
> > tackled - if required - in a different series).
>
> Yes, we have be talking about the CPU PM and CPU_CLUSTER_PM notifiers
> and I fully agree. It's something that we should look into and in
> future steps.
>
> >
> > Bottom line (talk is cheap, I know and apologise about that): this
> > series (up until this change) adds complexity to the idle path and lots
> > of code; if its usage is made optional and can be switched on on systems
> > where it saves power that's fine by me as long as we keep PSCI
> > OS-initiated idle states out of the equation, that's an orthogonal
> > discussion as, I hope, I managed to convey.
> >
> > Thanks,
> > Lorenzo
>
> Lorenzo, thanks for your feedback!
>
> Please, when you have time, could you also reply to the other thread
> we started, I would like to understand how I should proceed with this
> series.
OK, thanks, I will, sorry for the delay in responding.
Lorenzo
next prev parent reply other threads:[~2018-09-13 17:35 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 17:22 [PATCH v8 00/26] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 01/26] PM / Domains: Don't treat zero found compatible idle states as an error Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 02/26] PM / Domains: Deal with multiple states but no governor in genpd Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 03/26] PM / Domains: Add generic data pointer to genpd_power_state struct Ulf Hansson
2018-06-24 21:09 ` Rafael J. Wysocki
2018-06-25 8:34 ` Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 04/26] PM / Domains: Add support for CPU devices to genpd Ulf Hansson
2018-07-19 10:25 ` Rafael J. Wysocki
2018-08-03 11:43 ` Ulf Hansson
2018-08-06 9:36 ` Rafael J. Wysocki
2018-08-24 6:47 ` Ulf Hansson
2018-09-14 9:26 ` Rafael J. Wysocki
2018-06-20 17:22 ` [PATCH v8 05/26] PM / Domains: Add helper functions to attach/detach CPUs to/from genpd Ulf Hansson
2018-07-19 10:22 ` Rafael J. Wysocki
2018-08-03 11:44 ` Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 06/26] timer: Export next wakeup time of a CPU Ulf Hansson
2018-07-19 10:15 ` Rafael J. Wysocki
2018-06-20 17:22 ` [PATCH v8 07/26] PM / Domains: Add genpd governor for CPUs Ulf Hansson
2018-07-19 10:32 ` Rafael J. Wysocki
2018-07-26 9:14 ` Rafael J. Wysocki
2018-08-03 14:28 ` Ulf Hansson
2018-08-06 9:20 ` Rafael J. Wysocki
2018-08-09 15:39 ` Lorenzo Pieralisi
2018-08-24 9:26 ` Ulf Hansson
2018-08-24 10:38 ` Lorenzo Pieralisi
2018-08-30 13:36 ` Ulf Hansson
2018-09-13 15:37 ` Lorenzo Pieralisi [this message]
2018-09-14 9:50 ` Rafael J. Wysocki
2018-09-14 10:44 ` Lorenzo Pieralisi
2018-09-14 11:34 ` Rafael J. Wysocki
2018-09-14 12:30 ` Lorenzo Pieralisi
2018-08-24 8:29 ` Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 08/26] PM / Domains: Extend genpd CPU governor to cope with QoS constraints Ulf Hansson
2018-07-19 10:35 ` Rafael J. Wysocki
2018-08-03 11:42 ` Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs Ulf Hansson
2018-07-18 10:11 ` Rafael J. Wysocki
2018-07-19 10:12 ` Rafael J. Wysocki
2018-07-19 10:39 ` Rafael J. Wysocki
2018-08-03 11:42 ` Ulf Hansson
2018-08-06 9:37 ` Rafael J. Wysocki
2018-08-08 10:56 ` Lorenzo Pieralisi
2018-08-08 18:02 ` Lina Iyer
2018-08-09 8:16 ` Rafael J. Wysocki
2018-08-10 20:36 ` Lina Iyer
2018-08-12 9:53 ` Rafael J. Wysocki
2018-08-09 9:58 ` Sudeep Holla
2018-08-09 10:25 ` Lorenzo Pieralisi
2018-08-10 20:18 ` Lina Iyer
2018-08-15 10:44 ` Lorenzo Pieralisi
2018-08-24 12:24 ` Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 10/26] dt: psci: Update DT bindings to support hierarchical PSCI states Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 11/26] of: base: Add of_get_cpu_state_node() to get idle states for a CPU node Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 12/26] cpuidle: dt: Support hierarchical CPU idle states Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 13/26] drivers: firmware: psci: Move psci to separate directory Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 14/26] MAINTAINERS: Update files for PSCI Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 15/26] drivers: firmware: psci: Split psci_dt_cpu_init_idle() Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 16/26] drivers: firmware: psci: Support hierarchical CPU idle states Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 17/26] drivers: firmware: psci: Simplify error path of psci_dt_init() Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 18/26] drivers: firmware: psci: Announce support for OS initiated suspend mode Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 19/26] drivers: firmware: psci: Prepare to use " Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 20/26] drivers: firmware: psci: Share a few internal PSCI functions Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 21/26] drivers: firmware: psci: Add support for PM domains using genpd Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 22/26] drivers: firmware: psci: Introduce psci_dt_topology_init() Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 23/26] drivers: firmware: psci: Try to attach CPU devices to their PM domains Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 24/26] drivers: firmware: psci: Deal with CPU hotplug when using OSI mode Ulf Hansson
2018-11-19 19:50 ` Raju P L S S S N
2018-11-20 9:50 ` Ulf Hansson
2018-11-20 10:47 ` Raju P L S S S N
2018-06-20 17:22 ` [PATCH v8 25/26] arm64: kernel: Respect the hierarchical CPU topology in DT for PSCI Ulf Hansson
2018-06-20 17:22 ` [PATCH v8 26/26] arm64: dts: Convert to the hierarchical CPU topology layout for MSM8916 Ulf Hansson
2018-07-03 5:44 ` [PATCH v8 00/26] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) Ulf Hansson
2018-07-03 7:54 ` Rafael J. Wysocki
2018-07-09 11:42 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180913153727.GB6199@e107981-ln.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=fweisbec@gmail.com \
--cc=geert+renesas@glider.be \
--cc=ilina@codeaurora.org \
--cc=juri.lelli@arm.com \
--cc=khilman@kernel.org \
--cc=lina.iyer@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=tglx@linutronix.de \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).