Charles, On Thursday 19 June 2014 03:33 AM, Charles Garcia-Tobin wrote: > > >> -----Original Message----- >> From: Santosh Shilimkar [mailto:[email protected]] >> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
