Linux定时器中断

Question 1

Linux 定时器中断处理程序并没有做那么多事情直接地。对于 x86，您将找到默认的 PIT/HPET 定时器中断处理程序在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;
}

这将调用全局时钟事件的事件处理程序，tick_handler_periodic默认情况下，更新 jiffies 计数器，计算全局负载，并更新其他一些跟踪时间的地方。

作为中断发生的副作用，__schedule可能最终会被调用，因此定时器中断也可能导致任务切换（就像任何其他中断一样）。

改变配置_HZ更改定时器中断的周期。增加HZ意味着它触发的频率更高，因此与计时器相关的开销更多，但任务调度等待一段时间的机会更少（因此交互性得到改善）；减少HZ意味着它触发的频率较低，因此与计时器相关的开销较少，但任务等待调度的风险较高（因此吞吐量的提高是以交互响应能力为代价的）。与往常一样，最佳折衷方案取决于您的具体工作负载。无论如何，现在CONFIG_HZ与调度方面的相关性较小；看如何更改 Linux CPU 调度程序使用的时间片长度？

也可以看看Linux 中如何处理中断？

Answer

Linux 定时器中断处理程序并没有做那么多事情直接地。对于 x86，您将找到默认的 PIT/HPET 定时器中断处理程序在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;
}

这将调用全局时钟事件的事件处理程序，tick_handler_periodic默认情况下，更新 jiffies 计数器，计算全局负载，并更新其他一些跟踪时间的地方。

作为中断发生的副作用，__schedule可能最终会被调用，因此定时器中断也可能导致任务切换（就像任何其他中断一样）。

改变配置_HZ更改定时器中断的周期。增加HZ意味着它触发的频率更高，因此与计时器相关的开销更多，但任务调度等待一段时间的机会更少（因此交互性得到改善）；减少HZ意味着它触发的频率较低，因此与计时器相关的开销较少，但任务等待调度的风险较高（因此吞吐量的提高是以交互响应能力为代价的）。与往常一样，最佳折衷方案取决于您的具体工作负载。无论如何，现在CONFIG_HZ与调度方面的相关性较小；看如何更改 Linux CPU 调度程序使用的时间片长度？

也可以看看Linux 中如何处理中断？

Question 2

Linux 做什么在定时器中断？

我认为这是要求中间的动作。

我从中复制__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:

这是一个很好的起点；这是有据可查的。这是一个漫长故事的开始。什么是“唤醒”？与 R 和 S 状态有关吗？并阻止？

我对 SK 的回答和其中一个链接只有一点点反对：关于 HZ“不再那么重要”。

可能是因为过去存在一些混乱，从100HZ到1000HZ再回到300HZ的一些过度修正，所以要同时适应“多媒体”（想想HPET起源2005年：“多媒体计时器”）。

可以有 4 个或更多核心，这也不太重要。但根据您想要对“服务器”执行的操作，它仍然很重要 - 这种延迟/吞吐量权衡在重负载下可能很重要。

如果调度不是在定时器中断中完成的，那么它是在这些“其他”中断中完成的。

为什么 HZ 不可配置（启动甚至运行时）？

Answer