[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