[Query] How to measure the entry-latency-us and exit-latency-us on arm PSCI system

Jisheng Zhang jszhang at marvell.com
Mon Nov 16 19:56:02 PST 2015


On Mon, 16 Nov 2015 16:05:13 +0000
Lorenzo Pieralisi wrote:

> On Mon, Nov 16, 2015 at 08:10:55PM +0800, Jisheng Zhang wrote:
> > Hi all,
> > 
> > Now, I'd like to add cpuidle support to Marvell berlin arm64 soc via
> > drivers/cpuidle/dt_idle_states.c. The system is PSCI-1.0 compatible. 
> > 
> > Per my understanding:
> > 
> > The entry-latency-us: the time from beginning of cpuidle_idle_call()
> > to the firmware's last WFI instruction. Should test more times to find
> > the longest time.
> > 
> > The exit-latency-us: the time from the first instruction of waken up cpu
> > to the end of cpuidle_idle_call(). Should test more times to find the longest
> > time.
> > 
> > If cpufreq is available, we should fix the cpufreq to the lowest freq to do
> > the above test.
> > 
> > Even I have a look at idle-states binding doc, I'm still not sure whether my
> > solution to measure the entry-latency-us and exit-latency-us is correct or not,
> > could you please give suggestions?  
> 
> It is correct and yes for the time being they represent the global worst
> case so your assumption on cpufreq is reasonable, you should set the
> system in the worst case conditions.
> 
> If the entry phase is interruptible on pending irq (which means that
> your firmware has checkpoints in the power down sequence) please define
> wakeup-latency according to the docs, it might be < entry+exit,
> otherwise your measurements are just fine.
> 

Got it. Thanks for detailed explanations



More information about the linux-arm-kernel mailing list