devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).