Hi
Looks we are pretty much agreed on the number now.
In my e-mail though I was questioning what should be optional and what
shouldn't. The current proposal is that wakeup-latency-us is the optional
one, I was thinking that it's make more sense making entry/exit (given the
use is much more specific and yet to be proven) but frankly it is not great
shakes either way, so for me it's fine as it is. The only thing that I think
would be worth clarifying is that the text around wakeup-latency-us, to make
it clear when it makes sense to provide it. So I was thinking something
like:
- wakeup-latency-us:
Usage: Optional
Value type: <prop-encoded-array>
Definition: u32 value representing maximum delay between the
signalling of a wake-up event and the CPU being
able to execute normal code again. If omitted,
this is assumed to be equal to:
entry-latency-us + exit-latency-us
It is important to supply this value on systems
where the duration of PREP phase is
non-neglibigle. In such systems
entry-latency-us + exit-latency-us
will exceed wakeup-latency-us by this duration.
The other thing that may be worth adding is some graphs to help explain what
is meant by min-residency. Lorenzo feel free to take this or leave this. But
something like:
The energy consumption of a cpu when it enters a power state can be roughly
characterised by the following graph:
|
|
|
e |
n | /---
e | /------
r | /------
g | /-----
y | /------
| ----
| /|
| / |
| / |
| / |
| / |
| / |
|/ |
-----|-------+----------------------------------
0| 1 time
The graph starts with a steep slope and then a shallower one. The first part
denotes the energy costs incurred whilst entering and leaving the power
state. The shallower slope is essentially representing the power consumption
of the state.
We are defining min-residency for a given state as the period of time after
which choosing that state become the most energy efficient option. A good
way to visualise this, is if we take the same graph above and compare some
states. Due to the limitations of ascii art we are only showing two made up
states C1, and C2:
|
|
|
| /-- C1
e | /---
n | /----
e | /---
r | /---- /----------- C2
g | /-------/-------------
y | ------------ /---|
| / /---- |
| / /--- |
| / /---- |
| / /--- |
| --- |
| / |
| / |
|/ | time
---/----------------------------+------------------------
| better off with C1 | better off with C2
|
min-residency
for C2
As you can see, having taken into account entry/exit costs there is period
were C1 is the better choice of state. This is mainly down to the fact that
entry/exit costs are low. However the lower power consumption of C2 means
that after a suitable time, C2 is the better choice. This interval of time
is what we want to call min-residency
Cheers
Charles
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@xxxxxx]
> Sent: 19 June 2014 15:09
> To: Charles Garcia-Tobin; Lorenzo Pieralisi; Nicolas Pitre
> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; Mark Rutland; Sudeep Holla; Catalin
> Marinas; Rob Herring; grant.likely@xxxxxxxxxx; Peter De Schrijver;
> Daniel Lezcano; Amit Kucheria; Vincent Guittot; Antti Miettinen;
> Stephen Boyd; Kevin Hilman; Sebastian Capella; Tomasz Figa; Mark Brown;
> Paul Walmsley; Chander Kashyap
> Subject: Re: [PATCH v4 1/6] Documentation: arm: define DT idle states
> bindings
>
> Charles,
>
> On Thursday 19 June 2014 03:33 AM, Charles Garcia-Tobin wrote:
> >
> >
> >> -----Original Message-----
> >> From: Santosh Shilimkar [mailto:santosh.shilimkar@xxxxxx]
> >> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
