How to measure the entry-latency-us and exit-latency-us on arm PSCI system
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
Quoted 15 lines · 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.
Quoted 6 lines
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
Quoted 23 lines · On Mon, 16 Nov 2015 16:05:13 +0000 Lorenzo Pieralisi wrote:
Quoted 15 lines · 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.Quoted 6 lines
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?
Quoted 9 lines
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