| Message ID | 20210315114827.46036-1-psampat@linux.ibm.com |
|---|---|
| Headers | show |
| Series | CPU-Idle latency selftest framework | expand |
Hi Pratik, It just so happens that I have been trying Artem's version this last week, so I tried yours. On Mon, Mar 15, 2021 at 4:49 AM Pratik Rajesh Sampat <psampat@linux.ibm.com> wrote: > ... > To run this test specifically: > $ make -C tools/testing/selftests TARGETS="cpuidle" run_tests 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. > 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 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. On 18/03/21 2:30 am, Doug Smythies wrote: > Hi Pratik, > > It just so happens that I have been trying Artem's version this last > week, so I tried yours. > > On Mon, Mar 15, 2021 at 4:49 AM Pratik Rajesh Sampat > <psampat@linux.ibm.com> wrote: > ... >> To run this test specifically: >> $ make -C tools/testing/selftests TARGETS="cpuidle" run_tests > 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. Ah yes, this does need root privileges, I should have prefixed the command with sudo in the instructions for better understanding. >> 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 > Isn't it: > > tools/testing/selftests/cpuidle/cpuidle.log My bad, It was a typing error. I missed the "selftest" directory while typing it out. > ? 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 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? > 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. 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 > 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
On Wed, Mar 17, 2021 at 11:44 PM Pratik Sampat <psampat@linux.ibm.com> wrote: > > Hi Doug, > Thanks for trying these patches out. > > On 18/03/21 2:30 am, Doug Smythies wrote: > > Hi Pratik, > > > > It just so happens that I have been trying Artem's version this last > > week, so I tried yours. > > > > On Mon, Mar 15, 2021 at 4:49 AM Pratik Rajesh Sampat > > <psampat@linux.ibm.com> wrote: > > ... ... > > 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 > > 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? I didn't try it, I just did a hack so I could continue for this reply. > > 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. > > Question: Do you notice high variability with IPI test, Timer test or both? The IPI test has less variability than the Timer test. > > 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 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. > 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? 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): diff --git a/tools/testing/selftests/cpuidle/cpuidle.sh b/tools/testing/selftests/cpuidle/cpuidle.sh index de5141d5b76b..70bdacda5e91 100755 --- a/tools/testing/selftests/cpuidle/cpuidle.sh +++ b/tools/testing/selftests/cpuidle/cpuidle.sh @@ -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, On 20/03/21 8:34 pm, Doug Smythies wrote: > On Wed, Mar 17, 2021 at 11:44 PM Pratik Sampat <psampat@linux.ibm.com> wrote: >> Hi Doug, >> Thanks for trying these patches out. >> >> On 18/03/21 2:30 am, Doug Smythies wrote: >>> Hi Pratik, >>> >>> It just so happens that I have been trying Artem's version this last >>> week, so I tried yours. >>> >>> On Mon, Mar 15, 2021 at 4:49 AM Pratik Rajesh Sampat >>> <psampat@linux.ibm.com> wrote: >>> ... > ... >>> 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 >> 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? > I didn't try it, I just did a hack so I could continue for this reply. Sure. In subsequent version I could write something to cleanly handle online fail checks, maybe even specifically for CPU0. >>> 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. >> Question: Do you notice high variability with IPI test, Timer test or both? > The IPI test has less variability than the Timer test. > >> 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 > 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. 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 >> 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? > 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): > > diff --git a/tools/testing/selftests/cpuidle/cpuidle.sh > b/tools/testing/selftests/cpuidle/cpuidle.sh > index de5141d5b76b..70bdacda5e91 100755 > --- a/tools/testing/selftests/cpuidle/cpuidle.sh > +++ b/tools/testing/selftests/cpuidle/cpuidle.sh > @@ -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)
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