Bug 209617
| Summary: | tick_sched_timer wakes up the CPU 300+ times per second - Lenovo X1 Yoga gen 3 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Nate Graham (nate) |
| Component: | Config-Interrupts | Assignee: | Zhang Rui (rui.zhang) |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | rhiss, rui.zhang |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 5.8.14 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
powertop output
turbostat output Kernel config |
||
|
Description
Nate Graham
2020-10-12 00:35:39 UTC
can you attach the powertop and turbostat output when the system is runtime idle? For turbostat, the output of "turbostat -o ts-idle.out sleep 10" should be enough Created attachment 293405 [details]
powertop output
Sure!
Created attachment 293407 [details]
turbostat output
Im noticing the same behaviour on a Lenovo Ideapad S340 (Ryzen 5 3500U), on the 5.11.7 kernel version, and the last kernel version was able to find without this problem was the 5.4.101. the kernel is running in tickless mode, right? please attach the kernel config you're using. I don't know; how would I find out? I'm using the default kernel for openSUSE Tumbleweed. then please attach the kernel config you're using. Sorry, I need a little bit of hand-holding here. Where do I find that information? it depends. what distribution you're using? In ubuntu, it is saved as /boot/config-xxx, where xxx is the kernel version. You may google this a little bit based on your distribution. Created attachment 295989 [details]
Kernel config
Found it!
some hints CONFIG_HZ_250=y CONFIG_NO_HZ=y and you got 11139 within 10 seconds on a system which is 3.51% busy. CONFIG_HZ_250=y means that if the system is running with tick, you will got 250 timer interrupts per second, that is 10000 timer interrupts on 4 cpus in 10 seconds. And whether or not the system is running with tick depends on the workload you're running. I can not say 3.5% busy is an idle system based on my previous experience. So to me, the real problem is that what workload prevents the system from running without tick? 651 mW 546.1 µs/s 169.4 Interrupt [17] idma64.1 is there any network traffic or other IOs when this happens? Perhaps. But are you saying that tick_sched_timer is itself actually being woken up by apps? Can you help me understand what it is and what it does? most of the tick_sched_timer is introduced by the tick. if the system is busy, as you set tick to 250HZ, it means that the scheduler will set the tick every 1000ms / 250 = 4ms, and the system receives the tick timer interrupts every 4ms. if the system is idle, as we have enabled the tickless mode, it means that if the scheduler knows the CPU will be idle in the next tick, why bother set the timer interrupt and wakeup the CPU for nothing, right? then the cpu will be woken up by the next known event. So more idle the system is, less timer interrupt will be inserted for tick. Unless the system is totally idle, we can check if the system behaves as expected or not. In other cases, it highly depends on the workload the system is running. maybe apps, or maybe other things, basically anything can cause interrupts, like network traffic or other I/O activation. Thanks, that's very helpful. It's clear that this must be caused by the workload, which is to say issues with my installed software. I will follow up downstream. Closing this. |