关于降低Timer Softirq触发频率及本地中断相关问题的技术咨询

Great questions—let’s break this down clearly, since TIMER softirqs are a core part of kernel timing and scheduling.

What do TIMER softirqs actually do? #

TIMER softirqs are primarily triggered by local APIC timer interrupts, and they handle a range of critical kernel and user-space timing tasks:

• Process scheduling housekeeping: Update process time slices, calculate CPU load averages, and trigger scheduler decisions for task preemption.
• System time maintenance: Sync the wall clock (CLOCK_REALTIME) and monotonic clock (CLOCK_MONOTONIC) with hardware timer ticks.
• Delayed work execution: Run expired entries from the kernel’s delayed_work and workqueue systems (e.g., deferred cleanup tasks, periodic device polling).
• Network timing tasks: Manage TCP retransmission timers, keepalive probes, and other network stack timeouts.
• Memory management triggers: Wake up the kswapd daemon periodically to check for memory pressure and perform page reclaim if needed.

These tasks are queued to the CPU that received the original APIC timer interrupt, and run during softirq processing windows (right after a hard interrupt returns, or via ksoftirqd threads if the queue backs up).

Is adjusting APIC frequency the only way to reduce TIMER softirq counts? #

No, adjusting the local APIC timer frequency is not the only method—there are several other strategies to cut down on TIMER softirq triggers, depending on your workload:

• Use a tickless kernel (CONFIG_NO_HZ_FULL): Modern Linux kernels support disabling periodic timer ticks on CPUs running a single CPU-bound task or idle. Instead of firing a timer every CONFIG_HZ interval, the kernel only wakes the CPU when a specific timer (like a process timeout or network event) is due. This drastically reduces TIMER softirq frequency on those CPUs. Enable this via boot parameters like nohz_full=1,2 to target specific CPUs.
• Tweak CONFIG_HZ (compile-time option): The CONFIG_HZ setting defines the base kernel tick frequency (common values are 100, 250, 1000 Hz). Lowering this reduces periodic timer interrupts (and thus TIMER softirqs), but trades off with scheduling precision. Note this requires recompiling the kernel.
• Optimize timer usage: Audit user-space applications and kernel modules for unnecessary high-frequency timers. For example, user-space tools using setitimer with sub-millisecond intervals, or kernel drivers spawning unneeded periodic timers, can be modified to use longer intervals or one-shot timers instead.
• Adjust network timer parameters: For network-heavy workloads, increasing TCP timeouts (like tcp_retries2, tcp_keepalive_intvl) reduces the number of network-related TIMER softirq triggers.

Can TIMER softirqs from one CPU be delegated to another? #

This depends on the type of TIMER softirq:

• Periodic tick-related TIMER softirqs: These are tied directly to the local APIC timer of each CPU, as they handle CPU-specific tasks (like updating that CPU’s process time slices or load metrics). You cannot delegate these to another CPU—they must run on the CPU that received the original tick interrupt.
• Dynamic/one-shot timers: Many kernel and user-space timers (like hrtimer, timerfd, or user-space setitimer timers) are migratable. For example:
  • User-space timers follow the CPU affinity of their parent process. If you bind a process to CPU 3 using sched_setaffinity, its timers will trigger TIMER softirqs on CPU 3.
  • Kernel hrtimer instances can be marked with the HR_TIMER_MIGRATE flag, allowing the kernel to run their associated softirq work on an idle CPU instead of the one where the timer was scheduled.
• Workaround for high CPU load: If a specific CPU is overwhelmed by TIMER softirqs, use CONFIG_NO_HZ_FULL to disable periodic ticks on it. Any remaining timers (like network or application-specific ones) can be migrated to other CPUs via process affinity or migratable kernel timers.

内容的提问来源于stack exchange，提问作者Temporary TLB