[PATCH v4 1/6] Documentation: arm: define DT idle states bindings
Nicolas Pitre
nicolas.pitre at linaro.org
Wed Jun 18 14:09:48 PDT 2014
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.
Nicolas
More information about the linux-arm-kernel
mailing list