7

I have two questions about the Linux kernel. Specifically, does anybody know exactly, what Linux does in the timer interrupt? Is there some documentation about this? And what is affected when changing the CONFIG_HZ setting, when building the kernel?

Thanks in advance!

SimonC
  • 212
  • 1
    It would be helpful if you could indicate your background knowledge, and which other questions on this and related topics you already looked at (e.g. https://unix.stackexchange.com/questions/466722/how-to-change-the-length-of-time-slices-used-by-the-linux-cpu-scheduler/466723#466723 or https://unix.stackexchange.com/questions/549616/what-is-the-hardware-which-the-linux-kernel-uses-for-timer-interrupt) – AdminBee Nov 05 '19 at 09:56

2 Answers2

12

The Linux timer interrupt handler doesn’t do all that much directly. For x86, you’ll find the default PIT/HPET timer interrupt handler in arch/x86/kernel/time.c:

static irqreturn_t timer_interrupt(int irq, void *dev_id)
{
    global_clock_event->event_handler(global_clock_event);
    return IRQ_HANDLED;
}

This calls the event handler for global clock events, tick_handler_periodic by default, which updates the jiffies counter, calculates the global load, and updates a few other places where time is tracked.

As a side-effect of an interrupt occurring, __schedule might end up being called, so a timer interrupt can also lead to a task switch (like any other interrupt).

Changing CONFIG_HZ changes the timer interrupt’s periodicity. Increasing HZ means that it fires more often, so there’s more timer-related overhead, but less opportunity for task scheduling to wait for a while (so interactivity is improved); decreasing HZ means that it fires less often, so there’s less timer-related overhead, but a higher risk that tasks will wait to be scheduled (so throughput is improved at the expense of interactive responsiveness). As always, the best compromise depends on your specific workload. Nowadays CONFIG_HZ is less relevant for scheduling aspects anyway; see How to change the length of time-slices used by the Linux CPU scheduler?

See also How is an Interrupt handled in Linux?

Stephen Kitt
  • 434,908
1

what Linux does in the timer interrupt?

I take this as asking for the in-between actions.

I copy from that __schedule():

 *   3. Wakeups don't really cause entry into schedule(). They add a
 *      task to the run-queue and that's it.
 *
 *      Now, if the new task added to the run-queue preempts the current
 *      task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets
 *      called on the nearest possible occasion:

This is a good starting point; it is well documented. This is the start of a long story. What is a "wakeup"? Is it about R and S states? and blocking?

I have only one slight objection to S.K.'s answer, and to one of the links: about HZ being "not so important anymore".

Can be because there was some confusion in the past, some overcorrection from 100HZ to 1000HZ then back to 300HZ, so to fit "multimedia" at the same time (think of HPET origin 2005: "multimedia timer").

Can be with 4 and more cores it also matters less. But depending on what you want to do with your "server" it still should matter - this latency / throughput trade-off can be important under heavy load.

And if the scheduling is not done in the timer interrupts, then it is done in these "other" interrupts.

And why is HZ not configurable (boot or even runtime)?