一、时间子系统的软件架构
二、tick 层模块的文件
tick-common.c
tick-oneshot.c
tick-sched.c
tick-broadcast.c
tick-broadcast-hrtimer.c
这三个文件属于tick device layer。
tick-common.c文件是periodic tick模块，用于管理周期性tick事件。
tick-oneshot.c文件是for高精度timer的，用于管理高精度tick时间。
tick-sched.c是用于dynamic tick的。
tick-broadcast.c 和 tick-broadcast-hrtimer.c 是broadcast tick模块。
如果说每个.c文件是一个模块的话，我们可以首先简单描述tick device layer的各个模块。tick-common.c描述了tick device的一些通用操作，此外，该文件还包括了周期性tick的代码。想要让系统工作在tickless mode（更准确应该是Dynamic tick模块，也就是说根据系统的当前运行状况，动态的启停周期性tick）需要两个模块的支持，分别是tick-oneshot.c和tick-sched.c。tick-oneshot.c主要是提供和tick device的one shot mode相关的操作接口函数。从字面上看，tick-sched.c是和tick的调度相关，所谓tick的调度包括两个方面，一方面是在系统正常运行过程中，如何产生周期性的tick event，另一方面是在系统没有任务执行，进入idle状态的时候，如何停止周期性的tick，以及恢复的时候如何更新系统状态（例如：jiffies等）。tick-broadcast.c和tick-broadcast-hrtimer.c是和tick broadcast相关，本文不会涉及这部分的内容，会有专门的文档描述它
1、什么是tick
想要理解什么是tick device，什么是tickless kernel，首先当然要理解什么是tick？要理解什么是tick，首先要理解OS kernel是如何运作的。系统中有很多日常性的事情需要处理，例如：
－－－更新系统时间
－－－处理低精度timer
－－－处理正在运行进程的时间片信息
系统在处理这些事情的时候使用了轮询的方式，也就是说按照固定的频率去做这些操作。这时候就需要HW的协助，一般而言，硬件会有HW timer（称之system timer）可以周期性的trigger interrupt，让系统去处理上述的日常性事务。每次timer中断到来的时候，内核的各个模块就知道，一个固定的时间片已经过去。对于日常生活，tick这个概念是和钟表关联的：钟表会发出周期性的滴答的声音，这个声音被称为tick。CPU和OS kernel扩展了这个概念：周期性产生的timer中断事件被称为tick，而能够产生tick的设备就称为tick device。
如何选择tick的周期是需要在power comsuption、时间精度以及系统响应时间上进行平衡。我们考虑系统中基于tick的低精度timer模块，选择较高的tick频率会提高时间精度，例如对于，10ms的tick周期意味着低精度timer的时间精度就是10ms，设定3ms的低精度timer没有任何意义。为了提高时间精度，我们可以提高tick的频率，例如可以提升到1ms的tick，但是，这时更多的CPU的时间被花费在timer的中断处理，实际上，当系统不繁忙的时候，并不是每一个tick都是那么有意义，实际上大部分的tick到来的时候，OS kernel往往只是空转，实际上并有什么事情做，这对系统的power consumption是有害的。对于嵌入式设备，周期性的tick对power consumption危害更大，因为对于嵌入式设备，待机时间是一个很重要的指标，而周期性tick则意味着系统不可能真正的进入idle状态，而是会周期性的被wakeup，这些动作会吃掉电池的电量。同理，对于调度器而言亦然。如果设定10ms的tick，分配每个进程的时间片精度只是10ms，调度器计算每个进程占用CPU的时间也只能是以10ms为单位。为了提高进程时间片精度，我们可以提高tick的频率，例如可以提升到1ms的tick，但是，这时更多的CPU的时间被花费在进程上下文的切换上，但是，对应的好处是系统的响应时间会更短。
三、periodic tick 模块
1、数据结构
在内核中，使用struct tick_device来抽象系统中的tick设备，如下：
struct tick_device {
struct clock_event_device *evtdev;
enum tick_device_mode mode;
};
从上面的定义就可以看出：所谓tick device其实就是工作在某种模式下的clock event设备。工作模式体现在tick device的mode成员，evtdev指向了和该tick device关联的clock event设备。
tick device的工作模式定义如下：
enum tick_device_mode {
TICKDEV_MODE_PERIODIC,
TICKDEV_MODE_ONESHOT,
};
tick device可以工作在两种模式下，一种是周期性tick模式，另外一种是one shot模式。one shot模式主要和tickless系统以及高精度timer有关。
2、tick device的分类以及和CPU的关系
（1） local tick device。在单核系统中，传统的unix都是在tick驱动下进行任务调度、低精度timer触发等，在多核架构下，系统为每一个cpu建立了一个tick device，如下：
DEFINE_PER_CPU(struct tick_device, tick_cpu_device);
local tick device的clock event device应该具备下面的特点：
（a）该clock event device对应的HW timer必须是和该CPU core是有关联的的（也就是说，该hw timer的中断是可以送达到该CPU core的）。struct clock_event_device 有一个cpumask成员，它可以指示该clock event device为哪一个或者哪几个CPU core工作。如果采用ARM generic timer的硬件，其HW timer总是为一个CPU core服务的，我们称之为per cpu timer。
（b）该clock event device支持one shot模式，并且精度最高（rating最大）
（2）global tick device。具体定义如下：
int tick_do_timer_cpu __read_mostly = TICK_DO_TIMER_BOOT;
有些任务不适合在local tick device中处理，例如更新jiffies，更新系统的wall time，更新系统的平均负载（不是单一CPU core的负载），这些都是系统级别的任务，只需要在local tick device中选择一个作为global tick device就OK了。tick_do_timer_cpu指明哪一个cpu上的local tick作为global tick。
（3）broadcast tick device，定义如下：
static struct tick_device tick_broadcast_device;
我们会单独一份文档描述它，这里就不再描述了。
四、初始化tick device
1、注册一个新的clock event device的时候，tick device layer要做什么？
在clock_event的文章中，我们知道：底层的timer硬件驱动在初始化的时候会注册clock event device，在注册过程中就会调用tick_check_new_device函数来看看是否需要进行tick device的初始化，如果已经已经初始化OK的tick device是否有更换更高精度clock event device的需求。代码如下：
void tick_check_new_device(struct clock_event_device *newdev)
{
struct clock_event_device *curdev;
struct tick_device *td;
int cpu;cpu = smp_processor_id();－－－－－－－－－－－－－－－－－（1）
td = &per_cpu(tick_cpu_device, cpu);－－－获取当前cpu的tick device
curdev = td->evtdev; －－－目前tick device正在使用的clock event deviceif (!tick_check_percpu(curdev, newdev, cpu))－－－－－－－－－（2）
goto out_bc;if (!tick_check_preferred(curdev, newdev))－－－－－－－－－－－（3）
goto out_bc;if (!try_module_get(newdev->owner)) －－－－－增加新设备的reference count
return;
if (tick_is_broadcast_device(curdev)) { －－－－－－－－－－－－－（4）
clockevents_shutdown(curdev);
curdev = NULL;
}
clockevents_exchange_device(curdev, newdev); －－－通知clockevent layer
tick_setup_device(td, newdev, cpu, cpumask_of(cpu)); －－－－－－－－（5）
if (newdev->features & CLOCK_EVT_FEAT_ONESHOT)
tick_oneshot_notify();
return;out_bc:
tick_install_broadcast_device(newdev); －－－－其他文档中描述
}
（1）是否是为本CPU服务的clock event device？如果不是，那么不需要考虑per cpu tick device的初始化或者更换该cpu tick device的clock event device。当然，这是还是可以考虑用在broadcast tick device的。
（2）第二个关卡是per cpu的检查。如果检查不通过，那么说明这个新注册的clock event device和该CPU不来电，不能用于该cpu的local tick。如果注册的hw timer都是cpu local的（仅仅属于一个cpu，这时候该clock event device的cpumask只有一个bit被set），那么事情会比较简单。然而，事情往往没有那么简单，一个hw timer可以服务多个cpu。我们这里说HW timer服务于某个cpu其实最重要的是irq是否可以分发到指定的cpu上。我们可以看看tick_check_percpu的实现：
static bool tick_check_percpu(struct clock_event_device *curdev,
struct clock_event_device *newdev, int cpu)
{
if (!cpumask_test_cpu(cpu, newdev->cpumask))－－－－－－－－－（a）
return false;
if (cpumask_equal(newdev->cpumask, cpumask_of(cpu)))－－－－－－－－（b）
return true;
if (newdev->irq >= 0 && !irq_can_set_affinity(newdev->irq))－－－－－－－（c）
return false;
if (curdev && cpumask_equal(curdev->cpumask, cpumask_of(cpu)))－－－（d）
return false;
return true;
}
（a）判断这个新注册的clock event device是否可以服务该CPU，如果它根本不鸟这个cpu那么不用浪费时间了。
（b）判断这个新注册的clock event device是否只服务该CPU。如果这个clock event device就是服务该cpu的，那么别想三想四了，这个clock event device就是你这个CPU的人了。
（c）如果能走到这里，说明该clock event device可以服务多个CPU，指定的cpu（作为参数传递进来）只是其中之一而已，这时候，可以通过设定irq affinity将该clock event device的irq定向到该cpu。当前，前提是可以进行irq affinity的设定，这里就是进行这样的检查。
（d）走到这里，说明该新注册的clock event device是可以进行irq affinity设定的。我们可以通过修改irq affinity让该hw timer服务于这个指定的CPU。恩，听起来有些麻烦，的确如此，如果当前CPU的tick device正在使用的clock event device就是special for当前CPU的（根本不鸟其他CPU），有如此专情的clock event device，夫复何求，果断拒绝新注册的设备。
（3）程序来到这里，说明tick_check_percpu返回true，CPU和该clock event device之间的已经是眉目传情了，不过是否可以入主，就看该cpu的原配是否有足够强大的能力（精度和特性）。tick_check_preferred代码如下：
static bool tick_check_preferred(struct clock_event_device *curdev,
struct clock_event_device *newdev)
{
if (!(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) {－－－－－（a）
if (curdev && (curdev->features & CLOCK_EVT_FEAT_ONESHOT))
return false;
if (tick_oneshot_mode_active())
return false;
}return !curdev ||
newdev->rating > curdev->rating ||
!cpumask_equal(curdev->cpumask, newdev->cpumask);－－－－－－（b）
}
（a）首先进行one shot能力比拼。如果新的clock event device没有one shot能力而原配有，新欢失败。如果都没有one shot的能力，那么要看看当前系统是否启用了高精度timer或者tickless。本质上，如果clock event device没有oneshot功能，那么高精度timer或者tickless都是处于委曲求全的状态，如果这样，还是维持原配的委曲求全的状态，新欢失败
（b）如果current是NULL的话，事情变得非常简单，当然是新来的这个clock event device胜出了（这时候，后面的比较都没有意义了）。如果原配存在的话，那么可以看rating，如果新来的精度高，那也选择新来的clock event device。是否精度低就一定不选新的呢？也不是，新设备还是有机会力挽狂澜的：如果新来的是local timer，而原配是非local timer，这时候，也可以考虑选择新的，毕竟新来的clock event device是local timer，精度低一些也没有关系。
当tick_check_percpu返回true的时候有两种情况：一种是不管current是什么状态，新设备是CPU的local timer（只为这个cpu服务，即cpumask 和当前cpu相等）。另外一种情况是新设备不是CPU的local timer，当然原配也没有那么专一。
我们先看看第一种情况：如果cpumask_equal返回true，那么说明原配也是local timer，那么没有办法了，谁的rating高就选谁。如果cpumask_equal返回false，那么说明原配不是local timer，那么即便新来的rating低一些也还是优先选择local timer。
我们再看看第二种情况：新clock_event_device 虽然是个海王，但是可以设置中断亲和性，即可以给cpu 发生中断，同时本地的clock_event_device 不存在 或者 本地的clock_event_device 也是个海王，就返回true，进行下一轮的判断；
（4）OK，经过复杂的检查，我们终于决定要用这个新注册的clock event device来替代current了（当然，也有可能current根本不存在）。在进行替换之前，我们还有检查一下current是否是broadcast tick device，如果是的话，还不能将其退回clockevents layer，仅仅是设定其状态为shutdown。curdev = NULL这一句很重要，在clockevents_exchange_device函数中，如果curdev == NULL的话，old device将不会从全局链表中摘下，挂入clockevents_released链表。
（5）setup tick device，参考下一节描述。
2、如何Setup 一个 tick device？
所谓setup一个tick device就是对tick device心仪的clock event设备进行设置，并将该tick device的evtdev指向新注册的这个clock event device，具体代码如下：
static void tick_setup_device(struct tick_device *td,
struct clock_event_device *newdev, int cpu,
const struct cpumask *cpumask)
{
ktime_t next_event;
void (*handler)(struct clock_event_device *) = NULL;if (!td->evtdev) {
if (tick_do_timer_cpu == TICK_DO_TIMER_BOOT) {－－－－－－－（1）
……
}td->mode = TICKDEV_MODE_PERIODIC;－－－－－－－－－－（2）
} else {
handler = td->evtdev->event_handler;
next_event = td->evtdev->next_event;
td->evtdev->event_handler = clockevents_handle_noop; －－－－－－－（3）
}td->evtdev = newdev; －－－－－终于修成正果了，呵呵
if (!cpumask_equal(newdev->cpumask, cpumask)) －－－－－－－－－－－－－－－（4）
irq_set_affinity(newdev->irq, cpumask);if (tick_device_uses_broadcast(newdev, cpu)) －－－－－－－留给broadcast tick文档吧
return;if (td->mode == TICKDEV_MODE_PERIODIC)
tick_setup_periodic(newdev, 0); －－－－－－－－－－－－－－－－－－－－－－（5）
else
tick_setup_oneshot(newdev, handler, next_event); －－－－－其他文档描述
}
（1）在multi core的环境下，每一个CPU core都自己的tick device（可以称之local tick device），这些tick device中有一个被选择做global tick device，负责维护整个系统的jiffies。如果该tick device的是第一次设定，并且目前系统中没有global tick设备，那么可以考虑选择该tick设备作为global设备，进行系统时间和jiffies的更新。更细节的内容请参考timekeeping文档。
（2）在最初设定tick device的时候，缺省被设定为周期性的tick。当然，这仅仅是初始设定，实际上在满足一定的条件下，在适当的时间，tick device是可以切换到其他模式的，下面会具体描述。
（3）旧的clockevent设备就要退居二线了，将其handler修改为clockevents_handle_noop。
（4）如果不是local timer，那么还需要调用irq_set_affinity函数，将该clockevent的中断，定向到本CPU。
（5）tick_setup_periodic的代码如下（注：下面的代码分析中暂不考虑broadcast tick的情况）：
void tick_setup_periodic(struct clock_event_device *dev, int broadcast)
{
tick_set_periodic_handler(dev, broadcast); －－－－设定event handler为tick_handle_periodicif ((dev->features & CLOCK_EVT_FEAT_PERIODIC) && !tick_broadcast_oneshot_active()) {
clockevents_set_mode(dev, CLOCK_EVT_MODE_PERIODIC);－－－－－－－－－（a）
} else {
unsigned long seq;
ktime_t next;do {
seq = read_seqbegin(&jiffies_lock);
next = tick_next_period; －－－－－获取下一个周期性tick触发的时间
} while (read_seqretry(&jiffies_lock, seq));clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT); －－－模式设定
for (;;) {
if (!clockevents_program_event(dev, next, false)) －－－－program next clock event
return;
next = ktime_add(next, tick_period); －－－－－－计算下一个周期性tick触发的时间
}
}
}
（a）如果底层的clock event device支持periodic模式，那么直接调用clockevents_set_mode设定模式就OK了
（b）如果底层的clock event device不支持periodic模式，而tick device目前是周期性tick mode，那么要稍微复杂一些，需要用clock event device的one shot模式来实现周期性tick。
五、周期性tick的运作
1、从中断到clock event handler
一般而言，底层的clock event chip driver会注册中断，我们用ARM generic timer驱动为例，注册的代码如下：
…
err = request_percpu_irq(ppi, arch_timer_handler_phys, "arch_timer", arch_timer_evt);
……
具体的timer的中断handler如下：
static irqreturn_t arch_timer_handler_phys_mem(int irq, void *dev_id)
……
{
evt->event_handler(evt);
……
}
也就是说，在timer interrupt handler中会调用clock event device的event handler，而在周期性tick的场景下，这个event handler被设定为tick_handle_periodic。
2、周期性tick的clock event handler的执行分析
由于每个cpu都有自己的tick device，因此，在每个cpu上，每个tick到了的时候，都会调用tick_handle_periodic函数进行周期性tick中要处理的task，具体如下：
/*
* Event handler for periodic ticks
*/
void tick_handle_periodic(struct clock_event_device *dev)
{
int cpu = smp_processor_id();
ktime_t next = dev->next_event;tick_periodic(cpu); //周期性tick中要处理的内容
#if defined(CONFIG_HIGH_RES_TIMERS) || defined(CONFIG_NO_HZ_COMMON)
/*
* The cpu might have transitioned to HIGHRES or NOHZ mode via
* update_process_times() -> run_local_timers() ->
* hrtimer_run_queues().
*/
if (dev->event_handler != tick_handle_periodic)
return;
#endifif (!clockevent_state_oneshot(dev))
return;
for (;;) {
/*
* Setup the next period for devices, which do not have
* periodic mode:
*/
next = ktime_add(next, tick_period); //计算下一个周期性tick触发的时间if (!clockevents_program_event(dev, next, false))//设定下一个clock event触发的时间
return;
/*
* Have to be careful here. If we're in oneshot mode,
* before we call tick_periodic() in a loop, we need
* to be sure we're using a real hardware clocksource.
* Otherwise we could get trapped in an infinite
* loop, as the tick_periodic() increments jiffies,
* which then will increment time, possibly causing
* the loop to trigger again and again.
*/
if (timekeeping_valid_for_hres())
tick_periodic(cpu);
}
}
如果该tick device所属的clock event device工作在one shot mode，那么还需要为产生周期性tick而进行一些额外处理。
2、周期性tick中要处理的内容
代码如下：
/*
* Periodic tick
*/
static void tick_periodic(int cpu)
{
if (tick_do_timer_cpu == cpu) { //global tick需要进行一些额外处理
raw_spin_lock(&jiffies_lock);
write_seqcount_begin(&jiffies_seq);/* Keep track of the next tick event */
tick_next_period = ktime_add(tick_next_period, tick_period);do_timer(1); //更新jiffies，计算平均负载
write_seqcount_end(&jiffies_seq);
raw_spin_unlock(&jiffies_lock);
update_wall_time(); //更新wall time
}update_process_times(user_mode(get_irq_regs())); //更新和当前进程相关的内容
profile_tick(CPU_PROFILING);// 和性能剖析相关
}
六、dynamic tick 模块
1、什么是tickless？
tickless本质上上是去掉那个烦恼的滴答声音。对于OS kernel而言，tickless也就是意味着没有那个固定周期的timer interrupt事件，可是，没有那个固定的tick，OS kernel如何运转呢？
①首先看看如何处理timer。各种驱动和内核模块（例如网络子系统的TCP模块）都有timer的需求，因此，时间子系统需要管理所有注册到系统的timer。对于有tick的系统，在每个tick中scan所有的timer是一个顺理成章的想法，如果检查到timer超期（或者即将超期）系统会调用该timer的callback函数。当然，由于要在每个tick到来的时候检查timer，因此效率非常重要，内核有一些有意思的设计，有兴趣的读者可以看看低精度timer的的scan过程。
没有tick怎么办？这时候需要找到所有timer中最近要超期的timer，将其时间值设定到实际的HW timer中就OK了，当然，这时候需要底层的HW timer支持one shot，也就是说，该timer的中断就来一次，在该timer的的中断处理中除了处理超期函数之外，还需要scan所有timer，找到最近要超期的timer，将其时间值设定到实际的HW timer中就OK了，然后不断的重复上面的过程就OK了。假设系统中注册了1200ns, 1870ns, 2980ns, 4500ns, 5000ns和6250ns的timer，在一个HZ=1000的系统上，timer的超期都是在规则的tick时间点上，对于tickless的系统，timer的中断不是均匀的，具体如下图所示：
②我们再来看看更新系统时间。对于有tick的系统，非常简单，在每个tick到来的时候调用update_wall_time来更新系统时间，当然，由于是周期性tick，这时候每次都是累加相同的时间。对于tickless的系统，我们可以选择在每个timer超期的中断中调用update_wall_time来更新系统时间，不过，这种设计不好，一方面，如果系统中的timer数目太多，那么update_wall_time调用太频繁，而实际上是否系统需要这么高精度的时间值呢？更重要的是：timer中断到来是不确定的，和系统中的timer设定相关，有的时间段timer中断比较频繁，获取的系统时间精度比较高，有的时间段，timer中断比较稀疏，那么获取的系统时间精度比较低。
有一个问题：目前最新内核中，对于tickless 时，是如何更新wall_time ?
③看调度器怎么适应tickless。我们知道，除非你是一个完全基于优先级的调度器，否则系统都会给进程分配一个时间片（time slice），当占用CPU的时间片配额使用完了，该进程会挂入队列，等待调度器分配下一个时间片，并调度运行。有tick当然比较简单，在该tick的timer中断中减去当前进程的时间片。没有tick总是比较麻烦，我能想到的方法是：假设我们给进程分配40ms的时间片，那么在调度该进程的时候需要设定一个40ms的timer，timer到期后，调度器选择另外一个进程，然后再次设定timer。当然，如果没有进程优先级的概念（或者说优先级仅仅体现在分配的时间片比较多的情况下），并且系统中处于runnable状态的进程较少，整体的运作还是OK的。如果有优先级概念怎么办？如果进程执行过程中被中断打断，切换到另外的进程怎么办？如果系统内的进程数目很多如何保证调度器的性能？算了，太复杂了，还是有tick比较好，因此实际中，linux kernel在有任务执行的时候还是会启动周期性的tick。当然，世界上没有绝对正确的设计，任何优雅的设计都是适用于一定的应用场景的。其实自然界的规律不也是这样吗？牛顿的定律也不是绝对的正确，仅仅适用于低速的场景，当物体运动的速度接近光速的时候，牛顿的经典力学定律都失效了。
2、内核中的tickless
本节我们主要来看看内核中的tickless的情况。传统的unix和旧的linux（2000年初之前的）都是有tick的（对于新的内核，配置CONFIG_HZ_PERIODIC的情况下也是有tick的），新的linux kernel中增加了tickless的选项：
－－－CONFIG_NO_HZ_IDLE
－－－CONFIG_NO_HZ_FULL
CONFIG_NO_HZ_IDLE是说在系统dile的时候是没有tick的，当然，在系统运行的时候还是有tick的，因此，我们也称之dynamic tick或者NO HZ mode。3.10版本之后，引入一个full tickless mode，听起来好象任何情况下都是没有tick的，不过实际上也没有那么强，除了CPU处于idle的时候可以停下tick，当CPU上有且只有一个进程运行的时候，也可以停下周期性tick，其他的情况下，例如有多个进程等待调度执行，都还是有tick的。这个配置实际上只是对High-performance computing (HPC)有意义的，因此不是本文的重点。
3、tick device概述
Tick device是能够提供连续的tick event的设备。目前linux kernel中有periodic tick和one-shot tick两种tick device。periodic tick可以按照固定的时间间隔产生tick event。one-shot tick则是设定后只能产生一次tick event，如果要连续产生tick event，那么需要每次都进行设定。
每一个cpu都有属于自己的tick device。定义为tick_cpu_device。每一个tick device都有自己的类型（periodic或者one-shot），每一个tick device其实就是一个clock event device（增加了表示mode的member），不同类型的tick device有不同的event handler。对于periodic类型的tick设备，其clock event device的event handler是tick_handle_periodic（没有配置高精度timer）或者hrtimer_interrupt（配置了高精度timer）。对于one-shot类型的tick设备，其clock event device的event handler是hrtimer_interrupt（配置了高精度timer）或者tick_nohz_handler（没有配置高精度timer）。
Tick Device模块负责管理系统中的所有的tick设备，在SMP环境下，每一个CPU都自己的tick device，这些tick device中有一个被选择做global tick device，该device负责维护整个系统的jiffies以及更新哪些基于jiffies进行的全系统统计信息。
4、kernel如何初始化tick device layer以及周期性tick的运作？
如果把tick device的逻辑当作一个故事，那么故事的开始来自clockevent device layer。每当底层有新的clockevent device加入到系统中的时候，会调用clockevents_register_device或者clockevents_config_and_register向通用clockevent layer注册一个新的clockevent设备，这时候，会调用tick_check_new_device通知tick device layer有新货到来。如果tick device和clockevent device你情我愿，那么就会调用tick_setup_device函数setup这个tick device了。一般而言，刚系统初始化的时候，所有cpu的tick device都没有匹配clock event device，因此，该cpu的local tick device也就是global tick device了。而且，如果tick device是新婚（匹配之前，tick device的clock event device等于NULL），那么tick device的模式将被设定为TICKDEV_MODE_PERIODIC，即便clock event有one shot能力，即便系统配置了NO HZ。好吧，反正无论如何都需要从周期性tick开始，那么看看如何进行周期性tick的初始化的。
tick_setup_periodic函数用来设定一个periodic tick device。当然，最重要的设定event handler，对于周期性tick device，其clock event device的handler被设定为tick_handle_periodic。光有handler也不行，还得kick off底层的硬件，让其周期性的产生clock event，这样才能推动系统的运作（这是通过调用clockevent device layer的接口函数完成的）。
最后，我们思考一个问题：系统启动过程中，什么时候开始有tick？多核系统，BSP首先启动，在其初始化过程中会调用time_init，这里会启动clocksource的初始化过程。这时候，周期性的tick就会开始了。在某个阶段，其他的processor会启动，然后会注册其自己的local timer，这样，各个cpu上的tick就都启动了
七、设置了高精度timer的情况下，dynamic tick如何运作？
1、软件层次
下面的这幅图是以tick device为核心，描述了该模块和其他时间子系统模块的交互过程（配置高精度timer和dynamic tick的情况）：
上图中，红色边框的模块是per cpu的模块，所谓per cpu就是说每个cpu都会维护属于一个自己的对象。例如，对于tick device，每个CPU都会维护自己的tick device，不过，为了不让图片变得太大，上图只画了一个CPU的情况，其他CPU的动作是类似。为何clock event没有被涂上红色的边框呢？实际上clock event device并不是per cpu的，有些per cpu的local timer，也有global timer，如果硬件设计人员愿意的话，一个CPU可以有多个local timer，系统中所有的timer硬件被抽象成一个个的clock event device进行系统级别的管理，每个CPU并不会特别维护一个属于自己的clock event device。弱水三千，只取一瓢。每个CPU只会在众多clock event device中选取那个最适合自己的clock event device构建CPU local tick device。
tick device系统的驱动力来自中断子系统，当HW timer（tick device使用的那个）超期会触发中断，因此会调用hrtimer_interrupt来驱动高精度timer的运转（执行超期timer的call back函数）。而在hrtimer_interrupt中会扫描保存高精度timer的红黑树，找到下一个超期需要设定的时间，调用tick_program_event来设定下一次的超期事件，你知道的，这是我们的tick device工作在one shot mode，需要不断的set next expire time，才能驱动整个系统才会不断的向前。
传统的低精度timer是周期性tick驱动的，但是，目前tick 处于one shot mode，怎么办？只能是模拟了，Tick device layer需要设定一个周期性触发的高精度timer，在这个timer的超期函数中（tick_sched_timer）执行进行原来周期性tick的工作，例如触发TIMER_SOFTIRQ以便推动系统低精度timer的运作，更新timekeeping模块中的real clock。
2、如何切换到tickless
我们知道，开始tick device总是工作在周期性tick的mode，一切就像过去一样，无论何时，系统总是有那个周期性的tick到来。这个周期性的tick是由于硬件timer的中断推动，该HW Timer的中断会注册soft irq，因此，HW timer总会周期性的触发soft irq的执行，也就是run_timer_softirq函数。在该函数中会根据情况将hrtimer切换到高精度模式（hrtimer也有两种mode，一种高精度mode，一种是低精度mode，系统总是从低精度mode开始）。在系统切换到高精度timer mode的时候（hrtimer_switch_to_hres），由于高精度timer必须需要底层的tick device运行在one shot mode，因此，这时会调用tick_switch_to_oneshot函数将该CPU上的tick device的mode切换置one shot（Note：这时候event handler设定为hrtimer_interrupt）。同样的，底层的clock event device也会被设定为one shot mode。一旦进入one shot mode，那个周期性到来的timer中断就会消失了，从此系统只会根据系统中的hrtimer的设定情况来一次性的设定底层HW timer的触发。
3、如何产生周期性tick
虽然tick device以及底层的HW timer都工作在one shot mode，看起来系统的HW timer中断都是按需产生，多么美妙。但是，由于各种原因（此处省略3000字），在系统运行过程中，那个周期性的tick还需要保持，因此，在切换到one shot mode的同时，也会调用tick_setup_sched_timer函数创建一个sched timer（一个普通的hrtimer而已），该timer的特点就是每次超期后还会调用hrtimer_forward，不断的将自己挂回hrtimer的红黑树，于是乎，tick_sched_do_timer接口按照tick的周期不断的被调用，从而模拟了周期性的tick。
4、在idle的时候如何停掉tick
我们知道，各个cpu上的swapper进程（0号进程，又叫idle进程）最后都是会执行cpu_idle_loop函数，该函数在真正执行cpu idle指令之前会调用tick_nohz_idle_enter，在该函数中，sched timer会被停掉，因此，周期性的HW timer不会再来，这时候将cpu从idle中唤醒的只能是和实际上系统中的hrtimer中的那个最近的超期时间有关。
5、如何恢复tick
概念同上，当从idle中醒来，tick_nohz_idle_exit函数被调用，重建sched timer，一切恢复了原状。
6、没有设置高精度timer的情况下，dynamic tick如何运作？
