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

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

[Jisheng Zhang]

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?

Thanks in advance,
Jisheng

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

[Lorenzo Pieralisi]

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.

Thanks,
Lorenzo

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

[Jisheng Zhang]

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