CPU-Idle latency selftest framework

A kernel module + userspace driver to estimate the wakeup latency caused by going into stop states. The motivation behind this program is to find significant deviations behind advertised latency and residency values.

The patchset measures latencies for two kinds of events. IPIs and Timers As this is a software-only mechanism, there will additional latencies of the kernel-firmware-hardware interactions. To account for that, the program also measures a baseline latency on a 100 percent loaded CPU and the latencies achieved must be in view relative to that.

To achieve this, we introduce a kernel module and expose its control knobs through the debugfs interface that the selftests can engage with.

The kernel module provides the following interfaces within /sys/kernel/debug/latency_test/ for,

IPI test:
ipi_cpu_dest = Destination CPU for the IPI
ipi_cpu_src = Origin of the IPI
ipi_latency_ns = Measured latency time in ns
Timeout test:
timeout_cpu_src = CPU on which the timer to be queued timeout_expected_ns = Timer duration
timeout_diff_ns = Difference of actual duration vs expected timer

Sample output on a POWER9 system is as follows:
# --IPI Latency Test---
# Baseline Average IPI latency(ns): 3114
# Observed Average IPI latency(ns) - State0: 3265 # Observed Average IPI latency(ns) - State1: 3507 # Observed Average IPI latency(ns) - State2: 3739 # Observed Average IPI latency(ns) - State3: 3807 # Observed Average IPI latency(ns) - State4: 17070 # Observed Average IPI latency(ns) - State5: 1038174 # Observed Average IPI latency(ns) - State6: 1068784 #
# --Timeout Latency Test--
# Baseline Average timeout diff(ns): 1420
# Observed Average timeout diff(ns) - State0: 1640 # Observed Average timeout diff(ns) - State1: 1764 # Observed Average timeout diff(ns) - State2: 1715 # Observed Average timeout diff(ns) - State3: 1845 # Observed Average timeout diff(ns) - State4: 16581 # Observed Average timeout diff(ns) - State5: 939977 # Observed Average timeout diff(ns) - State6: 1073024

Things to keep in mind:

1. This kernel module + bash driver does not guarantee idleness on a core when the IPI and the Timer is armed. It only invokes sleep and hopes that the core is idle once the IPI/Timer is invoked onto it. Hence this program must be run on a completely idle system for best results

2. Even on a completely idle system, there maybe book-keeping tasks or jitter tasks that can run on the core we want idle. This can create outliers in the latency measurement. Thankfully, these outliers should be large enough to easily weed them out.

3. A userspace only selftest variant was also sent out as RFC based on suggestions over the previous patchset to simply the kernel complexeity. However, a userspace only approach had more noise in the latency measurement due to userspace-kernel interactions which led to run to run variance and a lesser accurate test. Another downside of the nature of a userspace program is that it takes orders of magnitude longer to complete a full system test compared to the kernel framework.
RFC patch: https://lkml.org/lkml/2020/9/2/356

4. For Intel Systems, the Timer based latencies don't exactly give out the measure of idle latencies. This is because of a hardware optimization mechanism that pre-arms a CPU when a timer is set to wakeup. That doesn't make this metric useless for Intel systems, it just means that is measuring IPI/Timer responding latency rather than idle wakeup latencies.
(Source: https://lkml.org/lkml/2020/9/2/610)
For solution to this problem, a hardware based latency analyzer is devised by Artem Bityutskiy from Intel.
https://youtu.be/Opk92aQyvt0?t=8266
https://intel.github.io/wult/

Pratik Rajesh Sampat (2):
cpuidle: Extract IPI based and timer based wakeup latency from idle
states
selftest/cpuidle: Add support for cpuidle latency measurement

 drivers/cpuidle/Makefile                   |   1 +
 drivers/cpuidle/test-cpuidle_latency.c     | 157 ++++++++++
 lib/Kconfig.debug                          |  10 +
 tools/testing/selftests/Makefile           |   1 +
 tools/testing/selftests/cpuidle/Makefile   |   6 +
 tools/testing/selftests/cpuidle/cpuidle.sh | 316 +++++++++++++++++++++
 tools/testing/selftests/cpuidle/settings   |   2 +
 7 files changed, 493 insertions(+)
 create mode 100644 drivers/cpuidle/test-cpuidle_latency.c
 create mode 100644 tools/testing/selftests/cpuidle/Makefile
 create mode 100755 tools/testing/selftests/cpuidle/cpuidle.sh
 create mode 100644 tools/testing/selftests/cpuidle/settings

2.17.1

Introduce a mechanism to fire directed IPIs from a specified source CPU to a specified target CPU and measure the difference in time incurred on wakeup.

Also, introduce a mechanism to queue a HR timer on a specified CPU and subsequently measure the time taken to wakeup the CPU.

Finally define a simple debugfs interface to control the knobs to fire the IPI and Timer events on specified CPU and view their incurred idle wakeup latencies.

---
 drivers/cpuidle/Makefile               |   1 +
 drivers/cpuidle/test-cpuidle_latency.c | 157 +++++++++++++++++++++++++
 lib/Kconfig.debug                      |  10 ++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/cpuidle/test-cpuidle_latency.c

index 26bbc5e74123..3b4ee06a9164 100644
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
 obj-$(CONFIG_DT_IDLE_STATES)		  += dt_idle_states.o
 obj-$(CONFIG_ARCH_HAS_CPU_RELAX)	  += poll_state.o
 obj-$(CONFIG_HALTPOLL_CPUIDLE)		  += cpuidle-haltpoll.o
+obj-$(CONFIG_IDLE_LATENCY_SELFTEST)	  += test-cpuidle_latency.o
 
 ##################################################################################
 # ARM SoC drivers

index 7937265ef879..3d6baea16913 100644
@@ -1467,6 +1467,16 @@ config DEBUG_KOBJECT
 	  If you say Y here, some extra kobject debugging messages will be sent
 	  to the syslog.
 
+config IDLE_LATENCY_SELFTEST
+	tristate "Cpuidle latency selftests"
+	depends on CPU_IDLE
+	help
+	  This option provides a kernel module that runs tests using the IPI and
+	  timers to measure latency.
+
+	  Say M if you want these self tests to build as a module.
+	  Say N if you are unsure.
+
 config DEBUG_KOBJECT_RELEASE
 	bool "kobject release debugging"
 	depends on DEBUG_OBJECTS_TIMERS

2.17.1

The cpuidle latency selftest provides support to systematically extract, analyse and present IPI and timer based wakeup latencies for each CPU and each idle state available on the system.

The selftest leverages test-cpuidle_latency module's debugfs interface to interact and extract latency information from the kernel.

The selftest inserts the module if already not inserted, disables all the idle states and enables them one by one testing the following:
1. Keeping source CPU constant, iterate through all the CPUS measuring IPI latency for baseline (CPU is busy with cat /dev/random > /dev/null workload) and then when the CPU is allowed to be at rest
2. Iterating through all the CPUs, sending expected timer durations to be equivalent to the residency of the deepest idle state enabled and extracting the difference in time between the time of wakeup and the expected timer duration

To run this test specifically:

$ make -C tools/testing/selftests TARGETS="cpuidle" run_tests

There are a few optinal arguments too that the script can take
[-h <help>]
[-m <location of the module>]
[-o <location of the output>]
[-v <verbose> (run on all cpus)]
Default Output location in: tools/testing/cpuidle/cpuidle.log

---
 tools/testing/selftests/Makefile           |   1 +
 tools/testing/selftests/cpuidle/Makefile   |   6 +
 tools/testing/selftests/cpuidle/cpuidle.sh | 316 +++++++++++++++++++++
 tools/testing/selftests/cpuidle/settings   |   2 +
 4 files changed, 325 insertions(+)
 create mode 100644 tools/testing/selftests/cpuidle/Makefile
 create mode 100755 tools/testing/selftests/cpuidle/cpuidle.sh
 create mode 100644 tools/testing/selftests/cpuidle/settings

index 8a917cb4426a..8ac7a4fb86f9 100644
@@ -7,6 +7,7 @@ TARGETS += cgroup
 TARGETS += clone3
 TARGETS += core
 TARGETS += cpufreq
+TARGETS += cpuidle
 TARGETS += cpu-hotplug
 TARGETS += drivers/dma-buf
 TARGETS += efivarfs

new file mode 100644
index 000000000000..cbe13feced34
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+all:
+
+TEST_PROGS := cpuidle.sh
+
+include ../lib.mk
\ No newline at end of file

new file mode 100644
index 000000000000..a26c38a70d77
@@ -0,0 +1,2 @@
+timeout=0
+

2.17.1

Hi Pratik,

It just so happens that I have been trying Artem's version this last week, so I tried yours.

...

While I suppose it should have been obvious, I interpreted the "$" sign to mean I could run as a regular user, which I can not.

Isn't it:

tools/testing/selftests/cpuidle/cpuidle.log

? At least, that is where my file was.

Other notes:

No idle state for CPU 0 ever gets disabled.
I assume this is because CPU 0 can never be offline,
so that bit of code (Disable all stop states) doesn't find its state. By the way, processor = Intel i5-9600K

The system is left with all idle states disabled, well not for CPU 0 as per the above comment. The suggestion is to restore them, otherwise my processor hogs 42 watts instead of 2.

My results are highly variable per test. My system is very idle:
Example (from turbostat at 6 seconds sample rate):

Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt RAMWatt
0.03    4600    153     28      2.03    1.89
0.01    4600    103     29      2.03    1.89
0.05    4600    115     29      2.08    1.89
0.01    4600    95      28      2.09    1.89
0.03    4600    114     28      2.11    1.89
0.01    4600    107     29      2.07    1.89
0.02    4600    102     29      2.11    1.89

...

... Doug

Hi Doug,
Thanks for trying these patches out.

Ah yes, this does need root privileges, I should have prefixed the command with sudo in the instructions for better understanding.

My bad, It was a typing error. I missed the "selftest" directory while typing it out.

I had tried these patches on an IBM POWER 9 processor and disabling CPU0's idle state works there. However, it does make sense for some processors to treat CPU 0 differently.
Maybe I could write in a case if idle state disabling fails for a CPU then we just skip it?

Question: Do you notice high variability with IPI test, Timer test or both?

I can think of two reasons for high run to run variance:

1. If you observe variance in timer tests, then I believe there could a mechanism of "C-state pre-wake" on some Intel machines at play here, which can pre-wake a CPU from an idle state when timers are armed. I'm not sure if the Intel platform that you're running on does that or not.

Artem had described this behavior to me a while ago and I think his wult page describes this behavior in more detail:
https://intel.github.io/wult/#c-state-pre-wake

2. I have noticed variability in results when there are kernel book-keeping or jitter tasks scheduled from time to time on an otherwise idle core. In the full per-CPU logs at tools/testing/selftests/cpuidle/cpuidle.log can you spot any obvious outliers per-CPU state?

Also you may want to run the test in verbose mode which runs for all the threads of each CPU with the following: "sudo ./cpuidle.sh -v". While latency mostly matters for per-core basis but it still maybe a good idea to see if that changes anything with the observations.

--
Thanks and regards,
Pratik

...

I didn't try it, I just did a hack so I could continue for this reply.

The IPI test has less variability than the Timer test.

Yes, I have reviewed all the references.
And yes, I think my processors have the pre-wake stuff.

I do not have the proper hardware to do the Artem pre-wake workaround method, but might buy it in future.

Yes.
I'll just paste in an example cpuidle.log file having used the -v option below, along with my hack job diff.

doug@s19:~/temp-k-git/linux/tools/testing/selftests/cpuidle$ cat
cpuidle.log.v3-1
--IPI Latency Test---
--Baseline IPI Latency measurement: CPU Busy--
SRC_CPU   DEST_CPU IPI_Latency(ns)
0            0          140
0            1          632
0            2          675
0            3          671
0            4          675
0            5          767
0            6          653
0            7          826
0            8          819
0            9          615
0           10          758
0           11          758
Baseline Avg IPI latency(ns): 665
---Enabling state: 0---
SRC_CPU   DEST_CPU IPI_Latency(ns)
0            0           76
0            1          484
0            2          494
0            3          539
0            4          498
0            5          491
0            6          474
0            7          434
0            8          544
0            9          476
0           10          447
0           11          467
Expected IPI latency(ns): 0
Observed Avg IPI latency(ns) - State 0: 452
---Enabling state: 1---
SRC_CPU   DEST_CPU IPI_Latency(ns)
0            0           72
0            1         1081
0            2          821
0            3         1486
0            4         1022
0            5          960
0            6         1634
0            7          933
0            8         1032
0            9         1046
0           10         1430
0           11         1338
Expected IPI latency(ns): 1000
Observed Avg IPI latency(ns) - State 1: 1071
---Enabling state: 2---
SRC_CPU   DEST_CPU IPI_Latency(ns)
0            0          264
0            1        30836
0            2        30562
0            3        30748
0            4        35286
0            5        30978
0            6         1952
0            7        36066
0            8        30670
0            9        30605
0           10        30635
0           11        35423
Expected IPI latency(ns): 120000
Observed Avg IPI latency(ns) - State 2: 27002
---Enabling state: 3---
SRC_CPU   DEST_CPU IPI_Latency(ns)
0            0           71
0            1        30853
0            2        32095
0            3        32661
0            4        30230
0            5        34348
0            6         2012
0            7        30816
0            8        30908
0            9        31130
0           10        34150
0           11        32050
Expected IPI latency(ns): 1034000
Observed Avg IPI latency(ns) - State 3: 26777

--Timeout Latency Test--
--Baseline Timeout Latency measurement: CPU Busy-- Wakeup_src Baseline_delay(ns)

0             453
1             568
2             387
3             337
4             433
5             579
6             330
7             400
8             561
9             544
10            569
11            523
Baseline Avg timeout diff(ns): 473
---Enabling state: 0---
Wakeup_src Baseline_delay(ns)  Delay(ns)
0             399
1             388
2             352
3             385
4             334
5             415
6             320
7             356
8             401
9             379
10            339
11            384

Expected timeout(ns): 200
Observed Avg timeout diff(ns) - State 0: 371
---Enabling state: 1---
Wakeup_src Baseline_delay(ns) Delay(ns)

0             666
1             575
2             608
3             590
4             608
5             552
6             582
7             593
8             597
9             587
10            588
11            610

Expected timeout(ns): 1200
Observed Avg timeout diff(ns) - State 1: 596
---Enabling state: 2---
Wakeup_src Baseline_delay(ns) Delay(ns)
0 36386
1 1069

2             866
3             884
4             850
5           55642
6          408082
7            1184
8          406075
9          406830
10         414105
11         406594

Expected timeout(ns): 360200
Observed Avg timeout diff(ns) - State 2: 178213
---Enabling state: 3---
Wakeup_src Baseline_delay(ns) Delay(ns)
0 406049
1 913
2 410134
3 921
4 406237
5 950
6 407181
7 920
8 407678
9 894
10 406320
11 304161
Expected timeout(ns): 3102200
Observed Avg timeout diff(ns) - State 3: 229363

My hack job, (CPUs always online):

b/tools/testing/selftests/cpuidle/cpuidle.sh
index de5141d5b76b..70bdacda5e91 100755

@@ -86,10 +86,6 @@ disable_idle()
 {
        for ((cpu=0; cpu<NUM_CPUS; cpu++))
        do
-               local cpu_status=$(cpu_is_online $cpu)
-               if [ $cpu_status == 0 ]; then
-                       continue
-               fi
                for ((state=0; state<NUM_STATES; state++))
                do
                        echo 1 >

/sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable @@ -104,10 +100,6 @@ op_state()

 {
        for ((cpu=0; cpu<NUM_CPUS; cpu++))
        do

- local cpu_status=$(cpu_is_online $cpu)
- if [ $cpu_status == 0 ]; then
- continue
- fi

                echo $1 >

/sys/devices/system/cpu/cpu$cpu/cpuidle/state$2/disable
done
}
@@ -124,17 +116,6 @@ cpuidle_disable_state()
op_state 1 $state
}

-cpu_is_online()
-{
- cpu=$1
- if [ ! -f "/sys/devices/system/cpu/cpu$cpu/online" ]; then
- echo 0
- return

-       fi
-       status=$(cat /sys/devices/system/cpu/cpu$cpu/online)
-       echo $status

-}
-
# Extract latency in microseconds and convert to nanoseconds extract_latency()
{
@@ -179,10 +160,6 @@ run_ipi_tests()

        printf "%s %10s %12s\n" "SRC_CPU" "DEST_CPU" "IPI_Latency(ns)" >> $LOG
        for ((cpu=0; cpu<NUM_CPUS; cpu+=SMT))
        do

- local cpu_status=$(cpu_is_online $cpu)
- if [ $cpu_status == 0 ]; then
- continue
- fi

                ipi_test_once "baseline" $cpu
                printf "%-3s %10s %12s\n" $src_cpu $cpu $ipi_latency >> $LOG
                avg_arr+=($ipi_latency)
@@ -198,10 +175,6 @@ run_ipi_tests()
                printf "%s %10s %12s\n" "SRC_CPU" "DEST_CPU"
"IPI_Latency(ns)" >> $LOG
                for ((cpu=0; cpu<NUM_CPUS; cpu+=SMT))
                do

- local cpu_status=$(cpu_is_online $cpu)
- if [ $cpu_status == 0 ]; then
- continue
- fi
# Running IPI test and logging results sleep 1
ipi_test_once "test" $cpu
@@ -262,10 +235,6 @@ run_timeout_tests()

        printf "%s %10s %10s\n" "Wakeup_src" "Baseline_delay(ns)">> $LOG
        for ((cpu=0; cpu<NUM_CPUS; cpu+=SMT))
        do

- local cpu_status=$(cpu_is_online $cpu)
- if [ $cpu_status == 0 ]; then
- continue
- fi

                timeout_test_once "baseline" $cpu 1000000
                printf "%-3s %13s\n" $src_cpu $timeout_diff >> $LOG
                avg_arr+=($timeout_diff)
@@ -281,10 +250,6 @@ run_timeout_tests()
                printf "%s %10s %10s\n" "Wakeup_src"
"Baseline_delay(ns)" "Delay(ns)" >> $LOG
                for ((cpu=0; cpu<NUM_CPUS; cpu+=SMT))
                do

- local cpu_status=$(cpu_is_online $cpu)
- if [ $cpu_status == 0 ]; then
- continue
- fi

                        timeout_test_once "test" $cpu 1000000
                        printf "%-3s %13s %18s\n" $src_cpu
$baseline_timeout_diff $timeout_diff >> $LOG
                        avg_arr+=($timeout_diff)

@@ -314,3 +279,7 @@ run_timeout_tests
printf "Removing $MODULE module\n"
printf "Full Output logged at: $LOG\n"
rmmod $MODULE
+
+printf "enabling idle states\n"
+
+echo 0 | tee /sys/devices/system/cpu/cpu*/cpuidle/state*/disable (END)

Hi Doug,

Sure. In subsequent version I could write something to cleanly handle online fail checks, maybe even specifically for CPU0.

That explains the variability that we are seeing in the Timer tests on the Intel processor you've tried on.
Also based on the data pasted below, it means that the IPI tests are more reliable than Timers.

Maybe it would be better to not run the Timer test on Intel platforms that support this pre-wakeup feature?
However, I don't know how (or if) Intel exposes this information to the userspace and if other platforms like AMD also have this feature in some form.

Another way of solving this problem could be to have the timer test as an optional parameter in the selftest for people to use while also printing a disclaimer for x86 users about the potential hardware design?

--
Thanks
Pratik