在定时器中断独立的系统是否是在内核模式或用户模式？(Is timer interrupt indep

在Linux单处理器系统，是定时器中断独立的系统是否是在内核模式或用户模式？

是否有定时器中断，而系统在内核模式中的任何不同的行为？

简单的回答是硬件时钟中断服务程序既没有执行，也不是动态计时器处理程序的调度是由模式中，系统是在硬件时钟中断前的影响。其原因是，在时钟定时器中断是立即提供服务的硬件中断，而不管所述执行是否是在内核或用户上下文（假设定时器中断被允许即是），并为时钟计时器中断服务程序中断自筹运行动态定时器处理程序的软件中断。

警告：1）我没有实际经验证明了这一点。 2）这并不适用于无滴答内核或HIGHRES计时器。

Linux内核代码使用单词“定时”是指几个不同的事情：

硬件定时器或时钟中断，让内核中的“滴答”
动态定时器 - 内核和驱动程序的软件计时器
间隔计时器 - （setitimer和报警系统调用）软件定时器对用户模式进程

硬件时钟或节拍定时器

在使用一个硬件时钟来提供“嘀”的系统中，时钟计时器中断是一个体系结构相关硬件中断。例如，寻找在“timer_interrupt” 弓/ PowerPC的/内核/ head_booke.h然后看看中断服务程序（ISR） timer_interrupt实施弓/ PowerPC的/内核/ time.c 。当定时器中断发生时，不管当前执行上下文的这ISR立即执行。此硬件中断不同于其它硬件中断虽然，在当它返回，处理不返回到前一个上下文。相反，进入调度。

对于被设置为每秒产生1000个时钟中断的系统中，有一个机会，当正被服务的其它中断时钟中断有时会被屏蔽。这通常被称为“失去的蜱虫”的问题。如果没有补偿丢失蜱，加载系统可以有时间减慢感。在某些体系结构内核使用更细粒度的硬件递增计数器，其值在读取并记录每个时钟定时器中断补偿失去的蜱。通过对比以前的滴答声的增量计数器值电流刻度的增量计数器的值，内核可以知道一个滴答已丢失。

该软件定时器

动态定时器处理程序的列表（使用set类型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)

我已经省略了设定的处理程序的initialilzations timer_interrupt到tick_handle_periodic ，并为处理器TIMER_SOFTIRQ 。

调用raise_softirq(TIMER_SOFTIRQ)产生的中断被立即提供服务的软件。该中断的ISR运行动态定时器队列。定时器处理程序的softirq上下文中运行，硬件中断启用。当ISR返回时，调度程序被调用。这意味着，如果有很多定时器设定的，不论过程恰好是在运行队列中下一个将被推迟。

如果有丢失的刻度，则定时器处理程序的执行过程可能会被推迟，但迟迟不运行时钟定时器中断之前，取决于执行的contect。

注意有关动态计时器精度

“......内核不能保证定时器功能将在其到期时间正确的开始。它只能确保他们无论是在适当的时间或之后的延迟长达几百毫秒执行。” 深入理解Linux内核 ，播威和Cesati，第三版，O'reilly的。

所以，如果你需要更好的计时器精度，则需要使用HIGHRES定时器。

参考文献：软件中断和实时