Bug 209617 - tick_sched_timer wakes up the CPU 300+ times per second - Lenovo X1 Yoga gen 3
Summary: tick_sched_timer wakes up the CPU 300+ times per second - Lenovo X1 Yoga gen 3
Status: RESOLVED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-12 00:35 UTC by Nate Graham
Modified: 2021-03-25 20:03 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.8.14
Tree: Mainline
Regression: No


Attachments
powertop output (5.23 KB, text/plain)
2020-11-02 21:25 UTC, Nate Graham
Details
turbostat output (5.39 KB, text/plain)
2020-11-02 21:26 UTC, Nate Graham
Details
Kernel config (240.79 KB, text/plain)
2021-03-22 13:21 UTC, Nate Graham
Details

Description Nate Graham 2020-10-12 00:35:39 UTC
I'm using a Lenovo X1 Yoga gen 3 laptop and am experiencing persistently low battery life (see Bug 208191). While troubleshooting that, I discovered with powertop that tick_sched_timer is consistently listed as having 300+ events per second. This is the typical output of powertop  on my system:

Summary: 1584.2 wakeups/second,  0.0 GPU ops/seconds, 0.0 VFS ops/sec and 71.8% CPU use

Power est.   Usage       Events/s    Category       Description
  3.75 W     45.0%                   Device         Display backlight
  1.37 W     6.7 ms/s     331.6      Timer          tick_sched_timer

This seems inappropriate.
Comment 1 Zhang Rui 2020-11-02 03:16:41 UTC
can you attach the powertop and turbostat output when the system is runtime idle?
Comment 2 Zhang Rui 2020-11-02 03:18:01 UTC
For turbostat, the output of "turbostat -o ts-idle.out sleep 10" should be enough
Comment 3 Nate Graham 2020-11-02 21:25:48 UTC
Created attachment 293405 [details]
powertop output

Sure!
Comment 4 Nate Graham 2020-11-02 21:26:07 UTC
Created attachment 293407 [details]
turbostat output
Comment 5 rhiss 2021-03-19 11:03:40 UTC
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.
Comment 6 Zhang Rui 2021-03-21 15:12:24 UTC
the kernel is running in tickless mode, right?
please attach the kernel config you're using.
Comment 7 Nate Graham 2021-03-21 15:58:50 UTC
I don't know; how would I find out? I'm using the default kernel for openSUSE Tumbleweed.
Comment 8 Zhang Rui 2021-03-22 03:13:59 UTC
then please attach the kernel config you're using.
Comment 9 Nate Graham 2021-03-22 03:15:07 UTC
Sorry, I need a little bit of hand-holding here. Where do I find that information?
Comment 10 Zhang Rui 2021-03-22 12:57:12 UTC
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.
Comment 11 Nate Graham 2021-03-22 13:21:42 UTC
Created attachment 295989 [details]
Kernel config

Found it!
Comment 12 Zhang Rui 2021-03-22 13:37:49 UTC
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?
Comment 13 Nate Graham 2021-03-23 19:43:42 UTC
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?
Comment 14 Zhang Rui 2021-03-25 03:37:24 UTC
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.
Comment 15 Zhang Rui 2021-03-25 03:39:44 UTC
maybe apps, or maybe other things, basically anything can cause interrupts, like  network traffic or other I/O activation.
Comment 16 Nate Graham 2021-03-25 20:03:24 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.