简单的答案是，硬件时钟中断服务例程的执行和动态定时器处理程序的调度都不受硬件时钟中断之前系统所处模式的影响。原因是时钟定时器中断是立即服务的硬件中断，无论执行是在内核还是用户上下文中（即假设定时器中断已启用），并且时钟定时器中断的中断服务程序其本身引发运行动态定时器处理程序的软件中断。
警告：1）我实际上还没有凭经验证明这一点。 2) 这不适用于无滴答内核或高分辨率计时器。
Linux 内核代码使用“定时器”一词来表示几种不同的含义：
- 为内核提供“滴答声”的硬件定时器或时钟中断
- 动态定时器 - 内核和驱动程序使用的软件定时器
- 间隔定时器 - （设置定时器和警报系统调用）用户模式进程的软件定时器
硬件时钟或滴答定时器
在使用硬件时钟提供“滴答声”的系统上，时钟定时器中断是依赖于体系结构的硬件中断。例如，在中查找“timer_interrupt”拱门/powerpc/kernel/head_booke.h http://lxr.free-electrons.com/source/arch/powerpc/kernel/head_booke.h?a=powerpc然后看中断服务程序（ISR）timer_interrupt实施于拱门/powerpc/内核/time.c http://lxr.free-electrons.com/source/arch/powerpc/kernel/time.c?v=3.0。当定时器中断发生时，该 ISR 立即执行，无论当前执行上下文如何。不过，此硬件中断与其他硬件中断不同，因为当它返回时，处理不会返回到先前的上下文。相反，进入调度程序。
对于设置为每秒产生 1000 个时钟中断的系统，当服务其他中断时，时钟中断有时可能会被屏蔽。这通常称为“丢失蜱”问题。如果不补偿丢失的滴答声，加载的系统可能会感觉时间变慢。在某些架构上，内核通过使用更细粒度的硬件增量计数器来补偿丢失的滴答声，该计数器的值在每个时钟定时器中断时被读取和记录。通过将当前tick的增量计数器值与前一个tick的增量计数器值进行比较，内核可以判断tick是否已丢失。
软件定时器
动态计时器处理程序列表（您使用linux/timer.h) 已过期的动态定时器在时钟定时器中断结束时、返回之前设置。顺序是（大约）：
[arch dependent]:timer_interrupt( )
kernel/time/tick-common.c:tick_handle_periodic( )
kernel/time/tick-common.c:tick_periodic( )
kernel/timer.c:update_process_times( )
kernel/timer.c:run_local_timers( )
kernel/softirq.c:raise_softirq(TIMER_SOFTIRQ)
我省略了设置处理程序的初始化timer_interrupt to tick_handle_periodic，以及处理程序TIMER_SOFTIRQ.
致电给raise_softirq(TIMER_SOFTIRQ)生成立即服务的软件中断。中断的 ISR 运行动态定时器队列。定时器处理程序在软中断上下文中运行，并启用硬件中断。当 ISR 返回时，调度程序被调用。这意味着，如果设置了很多计时器，则运行队列中的下一个进程将被延迟。
如果丢失了时钟周期，则定时器处理程序的执行可能会被延迟，但是，延迟并不取决于运行时钟定时器中断之前的执行内容。
关于动态定时器精度的注意事项
“……内核无法确保计时器函数在到期时间正确启动。它只能确保它们在适当的时间执行，或者在延迟最多几百毫秒后执行。”了解 Linux 内核，Bovet 和 Cesati，第三版，O'reilly。
因此，如果您需要更好的计时器精度，则需要使用高分辨率计时器。
参考：软件中断和实时性 https://lwn.net/Articles/520076/
