From: santosh.shilimkar@ti•com (Santosh Shilimkar)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v4 1/6] Documentation: arm: define DT idle states bindings
Date: Thu, 19 Jun 2014 10:08:31 -0400 [thread overview]
Message-ID: <53A2EEDF.4030403@ti.com> (raw)
In-Reply-To: <000001cf8b90$d6a6f090$83f4d1b0$@arm.com>
Charles,
On Thursday 19 June 2014 03:33 AM, Charles Garcia-Tobin wrote:
>
>
>> -----Original Message-----
>> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
>> Sent: 18 June 2014 20:27
>> To: Lorenzo Pieralisi; Nicolas Pitre
[..]
>>> +===========================================
>>> +3 - state node
>>> +===========================================
>>> +
>>> +A state node represents an idle state description and must be
>> defined as
>>> +follows:
>>> +
>>> +- state node
>>> +
>>> + Description: must be child of the idle-states node
>>> +
>>> + The state node name shall follow standard device tree naming
>>> + rules ([5], 2.2.1 "Node names"), in particular state nodes which
>>> + are siblings within a single common parent must be given a unique
>> name.
>>> +
>>> + The idle state entered by executing the wfi instruction
>> (idle_standby
>>> + SBSA,[3][4]) is considered standard on all ARM platforms and
>> therefore
>>> + must not be listed.
>>> +
>>> + To correctly specify idle states timing and energy related
>> properties,
>>> + the following definitions identify the different execution phases
>>> + a CPU goes through to enter and exit idle states and the implied
>>> + energy metrics:
>>> +
>>> +
>> ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]
>> __..
>>> + | | | | |
>>> +
>>> + |<------ entry ------->|
>>> + | latency |
>>> + |<- exit ->|
>>> + | latency |
>>> + |<-------- min-residency -------->|
>>> + |<------- wakeup-latency ------->|
>>> +
>> I don't know the wakeup latency makes much sense and also correct.
>> Hardware wakeup latency is actually exit latency. Is it for failed
>> or abort-able ilde case ? We are adding this as a new parameter
>> at least from idle states perspective. I think we should just
>> avoid it.
>>
>
> Hi Santosh,
>
> To me wake up latency makes up a lot of sense. It is not always the same as
> exit latency, it will depend on your system, and just how smart it is. In
> some cases the [ENTRY] period may not be negligible in which case exit
> latency will be less than the wake up latency.
> In addition, it will generally always be shorter than entry+exit which is
> the default value if omitted, this assumes the PREP time is not abortable,
> but this is the safer assumption to make.
> Wake up latency is really the number that folk have in their head for what
> you'd stick into the pm_qos to veto entry into states when you are latency
> constrained.
> The one thing that really is an optimisation here is having a separate exit
> latency, which is being proposed for use in core selection for the
> scheduler.
> So if anything was going to be made optional pending new scheduler patches
> should that not be entry/exit latency?
>
PM QOS angle Nico pointed out and its clear. The wakeup latency as such is a
worst case wakeup latency from QOS perspective so considering the aborted idle
case it makes sense to have conservative number which includes entry + exit.
If you look at current idle governors, only exit latency and target residency
is being used. No matter how we represent it, as long idle governor or idle
C-state selection logic gets that information, things should be fine. So
from that view your point of entry/exit optional makes sense considering
wakeup latency can convey that information indirectly.
Regards,
Santosh
next prev parent reply other threads:[~2014-06-19 14:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 16:18 [PATCH v4 0/6] ARM generic idle states Lorenzo Pieralisi
2014-06-11 16:18 ` [PATCH v4 1/6] Documentation: arm: define DT idle states bindings Lorenzo Pieralisi
2014-06-11 18:15 ` Nicolas Pitre
2014-06-13 16:49 ` Lorenzo Pieralisi
2014-06-13 17:33 ` Nicolas Pitre
2014-06-16 14:23 ` Lorenzo Pieralisi
2014-06-16 14:48 ` Nicolas Pitre
2014-06-18 17:36 ` Lorenzo Pieralisi
2014-06-18 18:20 ` Sebastian Capella
2014-06-18 19:27 ` Santosh Shilimkar
2014-06-18 20:51 ` Nicolas Pitre
2014-06-18 20:55 ` Santosh Shilimkar
2014-06-18 21:09 ` Nicolas Pitre
2014-06-18 23:13 ` Santosh Shilimkar
2014-06-19 7:33 ` Charles Garcia-Tobin
2014-06-19 14:08 ` Santosh Shilimkar [this message]
2014-06-19 15:09 ` Charles Garcia-Tobin
2014-06-18 21:03 ` Nicolas Pitre
2014-06-13 17:40 ` Sebastian Capella
2014-06-11 16:18 ` [PATCH v4 2/6] Documentation: devicetree: psci: define CPU suspend parameter Lorenzo Pieralisi
2014-06-11 16:18 ` [PATCH v4 3/6] drivers: cpuidle: implement OF based idle states infrastructure Lorenzo Pieralisi
2014-06-11 18:24 ` Nicolas Pitre
2014-06-12 8:46 ` Lorenzo Pieralisi
2014-06-11 18:25 ` Rafael J. Wysocki
2014-06-12 9:03 ` Lorenzo Pieralisi
2014-06-13 3:48 ` Preeti U Murthy
2014-06-13 17:16 ` Lorenzo Pieralisi
2014-07-06 10:01 ` Paul Burton
2014-06-11 18:38 ` Nicolas Pitre
2014-06-12 9:19 ` Lorenzo Pieralisi
2014-06-11 16:18 ` [PATCH v4 4/6] arm64: add PSCI CPU_SUSPEND based cpu_suspend support Lorenzo Pieralisi
2014-06-11 16:18 ` [PATCH v4 5/6] drivers: cpuidle: CPU idle ARM64 driver Lorenzo Pieralisi
2014-06-18 21:34 ` Daniel Lezcano
2014-06-19 9:30 ` Lorenzo Pieralisi
2014-06-19 3:02 ` Rob Herring
2014-06-19 9:08 ` Lorenzo Pieralisi
2014-06-11 16:18 ` [PATCH v4 6/6] arm64: boot: dts: update rtsm aemv8 dts with PSCI and idle states 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=53A2EEDF.4030403@ti.com \
--to=santosh.shilimkar@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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