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 19:24:23 +0000	[thread overview]
Message-ID: <20140317192422.GD28453@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140317.202638.1149319857823818469.apm@brigitte.kvy.fi>

On Mon, Mar 17, 2014 at 06:26:38PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > 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
> 
> Sorry, I should have explained myself more clearly. I've been
> pondering about these issues somewhat lately so I'm perhaps suffering
> from a bit of a tunnel vision.
> 
> In short, when we choose an idle state based on expected idle duration
> we are not comparing wfi against all possible idle states in turn and
> making a decision between wfi and state X. Instead we want to choose
> among all states the one that gives minimum energy for the expected
> idle time. I'll try to elaborate..
> 
> Entering and exiting idle states takes time at nonzero power. To make
> up for this lost energy we indeed want the time in the idle state to
> be sufficiently long to make up for the lost energy. Now the important
> question here is "make up compared to what?".
> 
> The energy over the idle time can be also interpreted as average
> power. When the idle time increases the average power for a state
> approaches the in-state power. A deeper idle state would be a state
> with lower in-state power and longer entry/exit time. Therefore the
> average power for a deeper idle state drops slower as function of idle
> time than the average power for a shallower idle state. If we'd plot
> the average power for a number of idle states as function of idle
> duration, we'd get a set of "constant over idle time plus constant"
> style curves. Average power for state 0 will drop fastest close to the
> in-state power of state 0. Average power for state 1 will drop slower
> and approach the in-state power of state 1, average power for state 2
> will drop even slower and approach the in-state power of state 3.
> 
> To define that the min-residency is the breakeven time against state 0
> means that we are looking at the curves and asking "when does the
> average power for state X cross the average power for state 0?". But
> that would be the guideline for making a decision between state 0 and
> the state in question. Even if average power for state 2 is below
> the average power of state 0 it is not necessarily yet below the
> average power of state 1. To break even against state 1 the idle
> duration needs to be longer.
> 
> Yet another way to look at this: for three states we can define three
> times of interest:
> - t1: the time when state1 breaks even against state0
> - t2: the time when state2 breaks even against state0
> - t3: the time when state2 breaks even against state1
> and t3 would typically be larger than t2.

Now it is crystal clear, and you are absolutely right, sorry for
misunderstanding.

Help me define it then please:

- min-residency-us

"u32 value representing time in microseconds required for the CPU to be in
the idle state to guarantee power savings maximization".

Rather vague (on purpose), if anyone comes up with a better definition please
shout.

Thanks !
Lorenzo

      reply	other threads:[~2014-03-17 19:24 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
2014-03-17 18:26           ` Antti P Miettinen
2014-03-17 19:24             ` Lorenzo Pieralisi [this message]

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=20140317192422.GD28453@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).