From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Antti P Miettinen <ananaza@iki.fi>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
"mturquette@linaro.org" <mturquette@linaro.org>,
"t.figa@samsung.com" <t.figa@samsung.com>,
"mark.hambleton@broadcom.com" <mark.hambleton@broadcom.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"nico@linaro.org" <nico@linaro.org>,
"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
"sebastian.capella@linaro.org" <sebastian.capella@linaro.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Dave P Martin <Dave.Martin@arm.com>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"khilman@linaro.org" <khilman@linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"galak@codeaurora.org" <galak@codeaurora.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
linux-arm-kernel@lists.infradea
Subject: Re: [PATCH RFC v4 3/3] Documentation: arm: define DT idle states bindings
Date: Mon, 17 Mar 2014 14:45:15 +0000 [thread overview]
Message-ID: <20140317144515.GC28453@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140317.154940.169167846103479320.apm@brigitte.kvy.fi>
On Mon, Mar 17, 2014 at 01:49:40PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Hi Antti,
> >
> > On Mon, Mar 17, 2014 at 11:15:07AM +0000, Antti P Miettinen wrote:
> >> Sorry for having been lazy in commenting..
> >
> > No worries, comments always welcome.
> >
> >> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Date: Tue, 18 Feb 2014 11:47:31 +0000
> >> > + - min-residency
> >> > + Usage: Required
> >> > + Value type: <prop-encoded-array>
> >> > + Definition: u32 value representing time in microseconds
> >> > + required for the CPU to be in the idle state to
> >> > + break even in power consumption terms compared
> >> > + to idle state idle_standby ([4][5]).
> >>
> >> To me this continues to be a bit illdefined. Say we have three states:
> >> 0,1,2. State 0 is the idle_standby. Providing a minimum residency for
> >> state 1 compared to state 0 sort of makes sense, but if we provide a
> >> minimum residency for state 2 compared to state 0 the break even time
> >> is going to be smaller than break even when comparing state 1 and
> >> state 2. With this data we'd enter state 2 when we'd be better off
> >> entering state 1.
> >
> > I am not sure I got your reply right, but min-residency for
> > state 2 will be higher than state 1, since it has to cater for the
> > dynamic power consumed by entering the state (but burns less power
> > than state 1 when _in_ the state).
> >
> > Entering a state has a power cost and min-residency should take that into
> > account, worst-case as per other stats.
> >
> > min-residency (and so the break-even) should take into account that
> > entering the state is not for free.
> >
> > I think that comparing against idle_standby is the only sane way we can
> > define that parameter, either that or we remove it.
> >
> > Does it make sense ?
> >
> > Thanks !
> > Lorenzo
>
> The point is that if you compare breakeven between state 0 and state 2
> the breakeven time will be smaller that when you compare the breakeven
> between state 1 and state 2. Assuming states ordered by "deepness" in
> the sense that deeper states have lower in-state power and longer
> entry/exit times.
>
> I guess you could specify that the min-residency defines the time when
> the state breaks even compared to the previous (shallower) state.
I am not following Antti I am sorry. States are ordered in terms of
power consumption which also means that deeper idle states have a longer
required min-residency to break even against idle_standby in order to actually
save power.
When we make a decision on what idle state to enter all we do, and
that's OS agnostic, is predicting (+checking the next event) the next IRQ and
see if it is worth entering a state or not. We have to compare it against
a baseline, which is the processor being in standbywfi and that's what
these bindings define.
I do not understand why you want to define min-residency against the
previous shallower state.
What this binding says is: standbywfi is the shallower idle state in
power consumption terms. Deeper idle states save more power than
standbywfi if the residency in that state is at least min-residency.
I do not see where the problem is to be honest, maybe I need an example.
Thanks!
Lorenzo
next prev parent reply other threads:[~2014-03-17 14:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 11:47 [PATCH RFC v4 0/3] ARM: defining idle states DT bindings Lorenzo Pieralisi
2014-02-18 11:47 ` [PATCH RFC v4 1/3] Documentation: devicetree: psci: define CPU suspend parameter Lorenzo Pieralisi
2014-02-18 11:47 ` [PATCH RFC v4 2/3] Documentation: arm: add cache DT bindings Lorenzo Pieralisi
2014-02-18 11:47 ` [PATCH RFC v4 3/3] Documentation: arm: define DT idle states bindings Lorenzo Pieralisi
2014-02-19 16:04 ` Sebastian Capella
2014-03-10 18:01 ` Lorenzo Pieralisi
2014-03-10 18:11 ` Sebastian Capella
2014-03-10 18:22 ` Sebastian Capella
2014-03-10 19:13 ` Rob Herring
2014-03-11 12:51 ` Lorenzo Pieralisi
2014-03-17 11:15 ` Antti P Miettinen
2014-03-17 11:53 ` Lorenzo Pieralisi
2014-03-17 13:49 ` Antti P Miettinen
2014-03-17 14:45 ` Lorenzo Pieralisi [this message]
2014-03-17 18:26 ` Antti P Miettinen
2014-03-17 19:24 ` Lorenzo Pieralisi
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=20140317144515.GC28453@e102568-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=Charles.Garcia-Tobin@arm.com \
--cc=Dave.Martin@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=ananaza@iki.fi \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradea \
--cc=linux-pm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.hambleton@broadcom.com \
--cc=mturquette@linaro.org \
--cc=nico@linaro.org \
--cc=robh+dt@kernel.org \
--cc=sebastian.capella@linaro.org \
--cc=t.figa@samsung.com \
--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).