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.
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]
Created attachment 293407 [details]
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]
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  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.