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 -- 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
