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: Wed, 18 Jun 2014 19:13:27 -0400 [thread overview]
Message-ID: <53A21D17.10206@ti.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1406181704240.16842@knanqh.ubzr>
On Wednesday 18 June 2014 05:09 PM, Nicolas Pitre wrote:
> On Wed, 18 Jun 2014, Santosh Shilimkar wrote:
>
>> On Wednesday 18 June 2014 04:51 PM, Nicolas Pitre wrote:
>>> On Wed, 18 Jun 2014, Santosh Shilimkar wrote:
>>>
>>>> On Wednesday 18 June 2014 01:36 PM, Lorenzo Pieralisi wrote:
>>>> [..]
>>>>> + 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.
>>>
>>> I explained the rationale for this parameter in a previous email but
>>> Lorenzo didn't carry it over. To be clearer, this should be "worst case
>>> wake-up latency". It is of interest for PMQOS. This is the maximum
>>> delay that can be expected from the moment a wake-up event is signaled
>>> and the moment the CPU is back operational. This is more than just exit
>>> latency. By default this is entry_latency + exit_latency but when there
>>> is an abortable PREP phase then it may be shorter than that.
>>>
>> PMQOS angle is right. It is just that the idle code is not
>> going to do anything with this value. But I see a value adding it
>> instead of some one doing calculation.
>
> The idle code should take it into account when a PMQOS restriction is in
> effect i.e. avoid using those modes whose worst case wake-up latency is
> too large.
>
> And cpuidle is being migrated into the scheduler as we speak. So some
> of the values there, namely entry_latency and exit_latency (taken
> separately for timing purposes) will be directly used by the scheduler
> to decide which CPU to wake up for example.
>
> So there is fundamentally 4 parameters if we want to comprehensively
> support all pertinent use cases.
>
Fair enough.
regards,
Santosh
next prev parent reply other threads:[~2014-06-18 23:13 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 [this message]
2014-06-19 7:33 ` Charles Garcia-Tobin
2014-06-19 14:08 ` Santosh Shilimkar
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=53A21D17.10206@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