Linux时间子系统

linux-dash

A beautiful web dashboard for Linux

项目地址：https://gitcode.com/gh_mirrors/li/linux-dash

免费下载资源

adaptiver

8086人浏览 · 2013-06-25 19:13:21

adaptiver · 2013-06-25 19:13:21 发布

在网上看到介绍介绍linux时间子系统的资料，绝对不错，有些地方写得比PLKA第15章还要好，转贴之。

原帖应该出自：

http://blog.csdn.net/droidphone/article/details/7975694

1. Linux时间子系统之一：clock source（时钟源）

http://blog.csdn.net/droidphone/article/details/7975694

clock source用于为linux内核提供一个时间基线，如果你用linux的date命令获取当前时间，内核会读取当前的clock source，转换并返回合适的时间单位给用户空间。在硬件层，它通常实现为一个由固定时钟频率驱动的计数器，计数器只能单调地增加，直到溢出为止。时钟源是内核计时的基础，系统启动时，内核通过硬件RTC获得当前时间，在这以后，在大多数情况下，内核通过选定的时钟源更新实时时间信息（墙上时间），而不再读取RTC的时间。本节的内核代码树基于V3.4.10。

/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！
/*****************************************************************************************************/

1. struct clocksource结构

内核用一个clocksource结构对真实的时钟源进行软件抽象，现在我们从clock source的数据结构开始，它的定义如下：

/**

* struct clocksource - hardware abstraction for a free running counter

* Provides mostly state-free accessors to the underlying hardware.

* This is the structure used for system time.

* @name: ptr to clocksource name

* @list: list head for registration

* @rating: rating value for selection (higher is better)

* To avoid rating inflation the following

* list should give you a guide as to how

* to assign your clocksource a rating

* 1-99: Unfit for real use

* Only available for bootup and testing purposes.

* 100-199: Base level usability.

* Functional for real use, but not desired.

* 200-299: Good.

* A correct and usable clocksource.

* 300-399: Desired.

* A reasonably fast and accurate clocksource.

* 400-499: Perfect

* The ideal clocksource. A must-use where

* available.

* @read: returns a cycle value, passes clocksource as argument

* @enable: optional function to enable the clocksource

* @disable: optional function to disable the clocksource

* @mask: bitmask for two's complement

* subtraction of non 64 bit counters

* @mult: cycle to nanosecond multiplier

* @shift: cycle to nanosecond divisor (power of two)

* @max_idle_ns: max idle time permitted by the clocksource (nsecs)

* @maxadj: maximum adjustment value to mult (~11%)

* @flags: flags describing special properties

* @archdata: arch-specific data

* @suspend: suspend function for the clocksource, if necessary

* @resume: resume function for the clocksource, if necessary

* @cycle_last: most recent cycle counter value seen by ::read()

struct clocksource {

* Hotpath data, fits in a single cache line when the

* clocksource itself is cacheline aligned.

cycle_t (*read)(struct clocksource *cs);

cycle_t cycle_last;

cycle_t mask;

u32 mult;

u32 shift;

u64 max_idle_ns;

u32 maxadj;

#ifdef CONFIG_ARCH_CLOCKSOURCE_DATA

struct arch_clocksource_data archdata;

#endif

const char *name;

struct list_head list;

int rating;

int (*enable)(struct clocksource *cs);

void (*disable)(struct clocksource *cs);

unsigned long flags;

void (*suspend)(struct clocksource *cs);

void (*resume)(struct clocksource *cs);

/* private: */

#ifdef CONFIG_CLOCKSOURCE_WATCHDOG

/* Watchdog related data, used by the framework */

struct list_head wd_list;

cycle_t cs_last;

cycle_t wd_last;

#endif

} ____cacheline_aligned;

我们只关注clocksource中的几个重要的字段。

1.1 rating：时钟源的精度

同一个设备下，可以有多个时钟源，每个时钟源的精度由驱动它的时钟频率决定，比如一个由10MHz时钟驱动的时钟源，他的精度就是100nS。clocksource结构中有一个rating字段，代表着该时钟源的精度范围，它的取值范围如下：

1--99：不适合于用作实际的时钟源，只用于启动过程或用于测试；

100--199：基本可用，可用作真实的时钟源，但不推荐；

200--299：精度较好，可用作真实的时钟源；

300--399：很好，精确的时钟源；

400--499：理想的时钟源，如有可能就必须选择它作为时钟源；

1.2 read回调函数

时钟源本身不会产生中断，要获得时钟源的当前计数，只能通过主动调用它的read回调函数来获得当前的计数值，注意这里只能获得计数值，也就是所谓的cycle，要获得相应的时间，必须要借助clocksource的mult和shift字段进行转换计算。

1.3 mult和shift字段

因为从clocksource中读到的值是一个cycle计数值，要转换为时间，我们必须要知道驱动clocksource的时钟频率F，一个简单的计算就可以完成：

t = cycle/F;

可是clocksource并没有保存时钟的频率F，因为使用上面的公式进行计算，需要使用浮点运算，这在内核中是不允许的，因此，内核使用了另外一个变通的办法，根据时钟的频率和期望的精度，事先计算出两个辅助常数mult和shift，然后使用以下公式进行cycle和t的转换：

t = (cycle * mult) >> shift;

只要我们保证：

F = (1 << shift) / mult;

内核内部使用64位进行该转换计算：

[cpp] view plain copy print ?

static inline s64 clocksource_cyc2ns(cycle_t cycles, u32 mult, u32 shift)

{

return ((u64) cycles * mult) >> shift;

}

从转换精度考虑，mult的值是越大越好，但是为了计算过程不发生溢出，mult的值又不能取得过大。为此内核假设cycle计数值被转换后的最大时间值：10分钟（600秒），主要的考虑是CPU进入IDLE状态后，时间信息不会被更新，只要在10分钟内退出IDLE，clocksource的cycle计数值就可以被正确地转换为相应的时间，然后系统的时间信息可以被正确地更新。当然最后的结果不一定是10分钟，它由clocksource_max_deferment进行计算，并保存max_idle_ns字段中，tickless的代码要考虑这个值，以防止在NO_HZ配置环境下，系统保持IDLE状态的时间过长。在这样，由10分钟这个假设的时间值，我们可以推算出合适的mult和shift值。

2. clocksource的注册和初始化

通常，clocksource要在初始化阶段通过clocksource_register_hz函数通知内核它的工作时钟的频率，调用的过程如下：

由上图可见，最终大部分工作会转由__clocksource_register_scale完成，该函数首先完成对mult和shift值的计算，然后根据mult和shift值，最终通过clocksource_max_deferment获得该clocksource可接受的最大IDLE时间，并记录在clocksource的max_idle_ns字段中。clocksource_enqueue函数负责按clocksource的rating的大小，把该clocksource按顺序挂在全局链表clocksource_list上，rating值越大，在链表上的位置越靠前。

每次新的clocksource注册进来，都会触发clocksource_select函数被调用，它按照rating值选择最好的clocksource，并记录在全局变量curr_clocksource中，然后通过timekeeping_notify函数通知timekeeping，当前clocksource已经变更，关于timekeeping，我将会在后续的博文中阐述。

3. clocksource watchdog

系统中可能同时会注册对个clocksource，各个clocksource的精度和稳定性各不相同，为了筛选这些注册的clocksource，内核启用了一个定时器用于监控这些clocksource的性能，定时器的周期设为0.5秒：

[cpp] view plain copy print ?

#define WATCHDOG_INTERVAL (HZ >> 1)

#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)

当有新的clocksource被注册时，除了会挂在全局链表clocksource_list外，还会同时挂在一个watchdog链表上：watchdog_list。定时器周期性地（0.5秒）检查watchdog_list上的clocksource，WATCHDOG_THRESHOLD的值定义为0.0625秒，如果在0.5秒内，clocksource的偏差大于这个值就表示这个clocksource是不稳定的，定时器的回调函数通过clocksource_watchdog_kthread线程标记该clocksource，并把它的rate修改为0，表示精度极差。

4. 建立clocksource的简要过程

在系统的启动阶段，内核注册了一个基于jiffies的clocksource，代码位于kernel/time/jiffies.c：

[cpp] view plain copy print ?

struct clocksource clocksource_jiffies = {

.name = "jiffies",

.rating = 1, /* lowest valid rating*/

.read = jiffies_read,

.mask = 0xffffffff, /*32bits*/

.mult = NSEC_PER_JIFFY << JIFFIES_SHIFT, /* details above */

.shift = JIFFIES_SHIFT,

};

......

static int __init init_jiffies_clocksource(void)

{

return clocksource_register(&clocksource_jiffies);

}

core_initcall(init_jiffies_clocksource);

它的精度只有1/HZ秒，rating值为1，如果平台的代码没有提供定制的clocksource_default_clock函数，它将返回该clocksource：

[cpp] view plain copy print ?

struct clocksource * __init __weak clocksource_default_clock(void)

{

return &clocksource_jiffies;

}

然后，在初始化的后段，clocksource的代码会把全局变量curr_clocksource设置为上述的clocksource：

[cpp] view plain copy print ?

static int __init clocksource_done_booting(void)

{

......

curr_clocksource = clocksource_default_clock();

......

finished_booting = 1;

......

clocksource_select();

......

return 0;

}

fs_initcall(clocksource_done_booting);

当然，如果平台级的代码在初始化时也会注册真正的硬件clocksource，所以经过clocksource_select()函数后，curr_clocksource将会被设为最合适的clocksource。如果clocksource_select函数认为需要切换更好的时钟源，它会通过timekeeping_notify通知timekeeping系统，使用新的clocksource进行时间计数和更新操作。

查看评论

3楼 gundamblade 2013-05-16 13:41发表 [回复] [引用] [举报]

你好，请问rating的值是怎么计算来的？

2楼 DroidPhone 2013-04-23 21:14发表 [回复] [引用] [举报]

呵呵，如果直接计算t=cycle/F，整除肯定不行，为了保证精度，就有了目前内核中的这种转换计算方法。

1楼 UStorage 2013-04-23 14:36发表 [回复] [引用] [举报]

你好，1.3节中
"可是clocksource并没有保存时钟的频率F，因为使用上面的公式进行计算，需要使用浮点运算"的说法是否有些问题呢？这应该不是一个浮点运算吧？kernel中使用mult和shift是否有其他考虑呢？
谢谢啦~

2. Linux时间子系统之二：表示时间的单位和结构

http://blog.csdn.net/droidphone/article/details/7979295

人们习惯用于表示时间的方法是：年、月、日、时、分、秒、毫秒、星期等等，但是在内核中，为了软件逻辑和代码的方便性，它使用了一些不同的时间表示方法，并为这些表示方法定义了相应的变量和数据结构，本节的内容就是阐述这些表示方法的意义和区别。

/*****************************************************************************************************/

声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！

/*****************************************************************************************************/

1. jiffies

内核用jiffies变量记录系统启动以来经过的时钟滴答数，它的声明如下：

extern u64 __jiffy_data jiffies_64;

extern unsigned long volatile __jiffy_data jiffies;

可见，在32位的系统上，jiffies是一个32位的无符号数，系统每过1/HZ秒，jiffies的值就会加1，最终该变量可能会溢出，所以内核同时又定义了一个64位的变量jiffies_64，链接的脚本保证jiffies变量和jiffies_64变量的内存地址是相同的，通常，我们可以直接访问jiffies变量，但是要获得jiffies_64变量，必须通过辅助函数get_jiffies_64来实现。jiffies是内核的低精度定时器的计时单位，所以内核配置的HZ数决定了低精度定时器的精度，如果HZ数被设定为1000，那么，低精度定时器（timer_list）的精度就是1ms=1/1000秒。因为jiffies变量可能存在溢出的问题，所以在用基于jiffies进行比较时，应该使用以下辅助宏来实现：

[cpp] view plain copy print ?

time_after(a,b)

time_before(a,b)

time_after_eq(a,b)

time_before_eq(a,b)

time_in_range(a,b,c)

time_after(a,b)

time_before(a,b)

time_after_eq(a,b)

time_before_eq(a,b)

time_in_range(a,b,c)

同时，内核还提供了一些辅助函数用于jiffies和毫秒以及纳秒之间的转换：

[cpp] view plain copy print ?

unsigned int jiffies_to_msecs(const unsigned long j);

unsigned int jiffies_to_usecs(const unsigned long j);

unsigned long msecs_to_jiffies(const unsigned int m);

unsigned long usecs_to_jiffies(const unsigned int u);

unsigned int jiffies_to_msecs(const unsigned long j);

unsigned int jiffies_to_usecs(const unsigned long j);

unsigned long msecs_to_jiffies(const unsigned int m);

unsigned long usecs_to_jiffies(const unsigned int u);

2. struct timeval

timeval由秒和微秒组成，它的定义如下：

struct timeval {

__kernel_time_t tv_sec; /* seconds */

__kernel_suseconds_t tv_usec; /* microseconds */

};

__kernel_time_t 和__kernel_suseconds_t 实际上都是long型的整数。gettimeofday和settimeofday使用timeval作为时间单位。

3. struct timespec

timespec由秒和纳秒组成，它的定义如下：

struct timespec {

__kernel_time_t tv_sec; /* seconds */

long tv_nsec; /* nanoseconds */

};

同样地，内核也提供了一些辅助函数用于jiffies、timeval、timespec之间的转换：

[cpp] view plain copy print ?

static inline int timespec_equal(const struct timespec *a, const struct timespec *b);

static inline int timespec_compare(const struct timespec *lhs, const struct timespec *rhs);

static inline int timeval_compare(const struct timeval *lhs, const struct timeval *rhs);

extern unsigned long mktime(const unsigned int year, const unsigned int mon,

const unsigned int day, const unsigned int hour,

const unsigned int min, const unsigned int sec);

extern void set_normalized_timespec(struct timespec *ts, time_t sec, s64 nsec);

static inline struct timespec timespec_add(struct timespec lhs, struct timespec rhs);

static inline struct timespec timespec_sub(struct timespec lhs, struct timespec rhs);

static inline s64 timespec_to_ns(const struct timespec *ts);

static inline s64 timeval_to_ns(const struct timeval *tv);

extern struct timespec ns_to_timespec(const s64 nsec);

extern struct timeval ns_to_timeval(const s64 nsec);

static __always_inline void timespec_add_ns(struct timespec *a, u64 ns);

[cpp] view plain copy print ?

unsigned long timespec_to_jiffies(const struct timespec *value);

void jiffies_to_timespec(const unsigned long jiffies, struct timespec *value);

unsigned long timeval_to_jiffies(const struct timeval *value);

void jiffies_to_timeval(const unsigned long jiffies, struct timeval *value);

timekeeper中的xtime字段用timespec作为时间单位。

4. struct ktime

linux的通用时间架构用ktime来表示时间，为了兼容32位和64位以及big-little endian系统，ktime结构被定义如下：

union ktime {

s64 tv64;

#if BITS_PER_LONG != 64 && !defined(CONFIG_KTIME_SCALAR)

struct {

# ifdef __BIG_ENDIAN

s32 sec, nsec;

# else

s32 nsec, sec;

# endif

} tv;

#endif

};

typedef union ktime ktime_t; /* Kill this */

64位的系统可以直接访问tv64字段，单位是纳秒，32位的系统则被拆分为两个字段：sec和nsec，并且照顾了大小端的不同。高精度定时器通常用ktime作为计时单位。下面是一些辅助函数用于计算和转换：

[cpp] view plain copy print ?

ktime_t ktime_set(const long secs, const unsigned long nsecs);

ktime_t ktime_sub(const ktime_t lhs, const ktime_t rhs);

ktime_t ktime_add(const ktime_t add1, const ktime_t add2);

ktime_t ktime_add_ns(const ktime_t kt, u64 nsec);

ktime_t ktime_sub_ns(const ktime_t kt, u64 nsec);

ktime_t timespec_to_ktime(const struct timespec ts);

ktime_t timeval_to_ktime(const struct timeval tv);

struct timespec ktime_to_timespec(const ktime_t kt);

struct timeval ktime_to_timeval(const ktime_t kt);

s64 ktime_to_ns(const ktime_t kt);

int ktime_equal(const ktime_t cmp1, const ktime_t cmp2);

s64 ktime_to_us(const ktime_t kt);

s64 ktime_to_ms(const ktime_t kt);

ktime_t ns_to_ktime(u64 ns);

3. Linux时间子系统之三：时间的维护者：timekeeper

本系列文章的前两节讨论了用于计时的时钟源：clocksource，以及内核内部时间的一些表示方法，但是对于真实的用户来说，我们感知的是真实世界的真实时间，也就是所谓的墙上时间，clocksource只能提供一个按给定频率不停递增的周期计数，如何把它和真实的墙上时间相关联？本节的内容正是要讨论这一点。

1. 时间的种类

内核管理着多种时间，它们分别是：

RTC时间

wall time：墙上时间

monotonic time

raw monotonic time

boot time：总启动时间

RTC时间在PC中，RTC时间又叫CMOS时间，它通常由一个专门的计时硬件来实现，软件可以读取该硬件来获得年月日、时分秒等时间信息，而在嵌入式系统中，有使用专门的RTC芯片，也有直接把RTC集成到Soc芯片中，读取Soc中的某个寄存器即可获取当前时间信息。一般来说，RTC是一种可持续计时的，也就是说，不管系统是否上电，RTC中的时间信息都不会丢失，计时会一直持续进行，硬件上通常使用一个后备电池对RTC硬件进行单独的供电。因为RTC硬件的多样性，开发者需要为每种RTC时钟硬件提供相应的驱动程序，内核和用户空间通过驱动程序访问RTC硬件来获取或设置时间信息。

xtime xtime和RTC时间一样，都是人们日常所使用的墙上时间，只是RTC时间的精度通常比较低，大多数情况下只能达到毫秒级别的精度，如果是使用外部的RTC芯片，访问速度也比较慢，为此，内核维护了另外一个wall time时间：xtime，取决于用于对xtime计时的clocksource，它的精度甚至可以达到纳秒级别，因为xtime实际上是一个内存中的变量，它的访问速度非常快，内核大部分时间都是使用xtime来获得当前时间信息。xtime记录的是自1970年1月1日24时到当前时刻所经历的纳秒数。

monotonic time 该时间自系统开机后就一直单调地增加，它不像xtime可以因用户的调整时间而产生跳变，不过该时间不计算系统休眠的时间，也就是说，系统休眠时，monotoic时间不会递增。

raw monotonic time 该时间与monotonic时间类似，也是单调递增的时间，唯一的不同是：raw monotonic time“更纯净”，他不会受到NTP时间调整的影响，它代表着系统独立时钟硬件对时间的统计。

boot time 与monotonic时间相同，不过会累加上系统休眠的时间，它代表着系统上电后的总时间。

时间种类	精度（统计单位）	访问速度	累计休眠时间	受NTP调整的影响
RTC	低	慢	Yes	Yes
xtime	高	快	Yes	Yes
monotonic	高	快	No	Yes
raw monotonic	高	快	No	No
boot time	高	快	Yes	Yes

2. struct timekeeper

内核用timekeeper结构来组织与时间相关的数据，它的定义如下：

/* Structure holding internal timekeeping values. */

struct timekeeper {

/* Current clocksource used for timekeeping. */

struct clocksource *clock;

/* NTP adjusted clock multiplier */

u32 mult;

/* The shift value of the current clocksource. */

int shift;

/* Number of clock cycles in one NTP interval. */

cycle_t cycle_interval;

/* Number of clock shifted nano seconds in one NTP interval. */

u64 xtime_interval;

/* shifted nano seconds left over when rounding cycle_interval */

s64 xtime_remainder;

/* Raw nano seconds accumulated per NTP interval. */

u32 raw_interval;

/* Clock shifted nano seconds remainder not stored in xtime.tv_nsec. */

u64 xtime_nsec;

/* Difference between accumulated time and NTP time in ntp

* shifted nano seconds. */

s64 ntp_error;

/* Shift conversion between clock shifted nano seconds and

* ntp shifted nano seconds. */

int ntp_error_shift;

/* The current time */

struct timespec xtime;

* wall_to_monotonic is what we need to add to xtime (or xtime corrected

* for sub jiffie times) to get to monotonic time. Monotonic is pegged

* at zero at system boot time, so wall_to_monotonic will be negative,

* however, we will ALWAYS keep the tv_nsec part positive so we can use

* the usual normalization.

* wall_to_monotonic is moved after resume from suspend for the

* monotonic time not to jump. We need to add total_sleep_time to

* wall_to_monotonic to get the real boot based time offset.

* - wall_to_monotonic is no longer the boot time, getboottime must be

* used instead.

struct timespec wall_to_monotonic;

/* time spent in suspend */

struct timespec total_sleep_time;

/* The raw monotonic time for the CLOCK_MONOTONIC_RAW posix clock. */

struct timespec raw_time;

/* Seqlock for all timekeeper values */

seqlock_t lock;

};

其中的xtime字段就是上面所说的墙上时间，它是一个timespec结构的变量，它记录了自1970年1月1日以来所经过的时间，因为是timespec结构，所以它的精度可以达到纳秒级，当然那要取决于系统的硬件是否支持这一精度。

内核除了用xtime表示墙上的真实时间外，还维护了另外一个时间：monotonic time，可以把它理解为自系统启动以来所经过的时间，该时间只能单调递增，可以理解为xtime虽然正常情况下也是递增的，但是毕竟用户可以主动向前或向后调整墙上时间，从而修改xtime值。但是monotonic时间不可以往后退，系统启动后只能不断递增。奇怪的是，内核并没有直接定义一个这样的变量来记录monotonic时间，而是定义了一个变量wall_to_monotonic，记录了墙上时间和monotonic时间之间的偏移量，当需要获得monotonic时间时，把xtime和wall_to_monotonic相加即可，因为默认启动时monotonic时间为0，所以实际上wall_to_monotonic的值是一个负数，它和xtime同一时间被初始化，请参考timekeeping_init函数。

计算monotonic时间要去除系统休眠期间花费的时间，内核用total_sleep_time记录休眠的时间，每次休眠醒来后重新累加该时间，并调整wall_to_monotonic的值，使其在系统休眠醒来后，monotonic时间不会发生跳变。因为wall_to_monotonic值被调整。所以如果想获取boot time，需要加入该变量的值：

/**

* get_monotonic_boottime - Returns monotonic time since boot

* @ts: pointer to the timespec to be set

* Returns the monotonic time since boot in a timespec.

* This is similar to CLOCK_MONTONIC/ktime_get_ts, but also

* includes the time spent in suspend.

void get_monotonic_boottime(struct timespec *ts)

{

struct timespec tomono, sleep;

unsigned int seq;

s64 nsecs;

WARN_ON(timekeeping_suspended);

do {

seq = read_seqbegin(&timekeeper.lock);

*ts = timekeeper.xtime;

tomono = timekeeper.wall_to_monotonic;

sleep = timekeeper.total_sleep_time;

nsecs = timekeeping_get_ns();

} while (read_seqretry(&timekeeper.lock, seq));

set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec + sleep.tv_sec,

(s64)ts->tv_nsec + tomono.tv_nsec + sleep.tv_nsec + nsecs);

}

EXPORT_SYMBOL_GPL(get_monotonic_boottime);

raw_time字段用来表示真正的硬件时间，也就是上面所说的raw monotonic time，它不受时间调整的影响，monotonic时间虽然也不受settimeofday的影响，但会受到ntp调整的影响，但是raw_time不受ntp的影响，他真的就是开完机后就单调地递增。xtime、monotonic-time和raw_time可以通过用户空间的clock_gettime函数获得，对应的ID参数分别是 CLOCK_REALTIME、CLOCK_MONOTONIC、CLOCK_MONOTONIC_RAW。

clock字段则指向了目前timekeeper所使用的时钟源，xtime，monotonic time和raw time都是基于该时钟源进行计时操作，当有新的精度更高的时钟源被注册时，通过timekeeping_notify函数，change_clocksource函数将会被调用，timekeeper.clock字段将会被更新，指向新的clocksource。

早期的内核版本中，xtime、wall_to_monotonic、raw_time其实是定义为全局静态变量，到我目前的版本（V3.4.10），这几个变量被移入到了timekeeper结构中，现在只需维护一个timekeeper全局静态变量即可：

static struct timekeeper timekeeper;

3. timekeeper的初始化

timekeeper的初始化由timekeeping_init完成，该函数在start_kernel的初始化序列中被调用，timekeeping_init首先从RTC中获取当前时间：

void __init timekeeping_init(void)

{

struct clocksource *clock;

unsigned long flags;

struct timespec now, boot;

read_persistent_clock(&now);

read_boot_clock(&boot);

然后对锁和ntp进行必要的初始化：

seqlock_init(&timekeeper.lock);

ntp_init();

接着获取默认的clocksource，如果平台没有重新实现clocksource_default_clock函数，默认的clocksource就是基于jiffies的clocksource_jiffies，然后通过timekeeper_setup_inernals内部函数把timekeeper和clocksource进行关联：

write_seqlock_irqsave(&timekeeper.lock, flags);

clock = clocksource_default_clock();

if (clock->enable)

clock->enable(clock);

timekeeper_setup_internals(clock);

利用RTC的当前时间，初始化xtime，raw_time，wall_to_monotonic等字段：

timekeeper.xtime.tv_sec = now.tv_sec;

timekeeper.xtime.tv_nsec = now.tv_nsec;

timekeeper.raw_time.tv_sec = 0;

timekeeper.raw_time.tv_nsec = 0;

if (boot.tv_sec == 0 && boot.tv_nsec == 0) {

boot.tv_sec = timekeeper.xtime.tv_sec;

boot.tv_nsec = timekeeper.xtime.tv_nsec;

}

set_normalized_timespec(&timekeeper.wall_to_monotonic,

-boot.tv_sec, -boot.tv_nsec);

最后，初始化代表实时时间和monotonic时间之间偏移量的offs_real字段，total_sleep_time字段初始化为0：

timekeeper.total_sleep_time.tv_sec = 0;

timekeeper.total_sleep_time.tv_nsec = 0;

write_sequnlock_irqrestore(&timekeeper.lock, flags);

}

xtime字段因为是保存在内存中，系统掉电后无法保存时间信息，所以每次启动时都要通过timekeeping_init从RTC中同步正确的时间信息。其中，read_persistent_clock和read_boot_clock是平台级的函数，分别用于获取RTC硬件时间和启动时的时间，不过值得注意到是，到目前为止（我的代码树基于3.4版本），ARM体系中，只有tegra和omap平台实现了read_persistent_clock函数。如果平台没有实现该函数，内核提供了一个默认的实现：

/**

* read_persistent_clock - Return time from the persistent clock.

* Weak dummy function for arches that do not yet support it.

* Reads the time from the battery backed persistent clock.

* Returns a timespec with tv_sec=0 and tv_nsec=0 if unsupported.

* XXX - Do be sure to remove it once all arches implement it.

void __attribute__((weak)) read_persistent_clock(struct timespec *ts)

{

ts->tv_sec = 0;

ts->tv_nsec = 0;

}

/**

* read_boot_clock - Return time of the system start.

* Weak dummy function for arches that do not yet support it.

* Function to read the exact time the system has been started.

* Returns a timespec with tv_sec=0 and tv_nsec=0 if unsupported.

* XXX - Do be sure to remove it once all arches implement it.

void __attribute__((weak)) read_boot_clock(struct timespec *ts)

{

ts->tv_sec = 0;

ts->tv_nsec = 0;

}

那么，其他ARM平台是如何初始化xtime的？答案就是CONFIG_RTC_HCTOSYS这个内核配置项，打开该配置后，driver/rtc/hctosys.c将会编译到系统中，由rtc_hctosys函数通过do_settimeofday在系统初始化时完成xtime变量的初始化：

static int __init rtc_hctosys(void)

{

int err = -ENODEV;

struct rtc_time tm;

struct timespec tv = {

.tv_nsec = NSEC_PER_SEC >> 1,

};

struct rtc_device *rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);

if (rtc == NULL) {

pr_err("%s: unable to open rtc device (%s)\n",

__FILE__, CONFIG_RTC_HCTOSYS_DEVICE);

goto err_open;

}

err = rtc_read_time(rtc, &tm);

if (err) {

dev_err(rtc->dev.parent,

"hctosys: unable to read the hardware clock\n");

goto err_read;

}

err = rtc_valid_tm(&tm);

if (err) {

dev_err(rtc->dev.parent,

"hctosys: invalid date/time\n");

goto err_invalid;

}

rtc_tm_to_time(&tm, &tv.tv_sec);

do_settimeofday(&tv);

dev_info(rtc->dev.parent,

"setting system clock to "

"%d-%02d-%02d %02d:%02d:%02d UTC (%u)\n",

tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,

tm.tm_hour, tm.tm_min, tm.tm_sec,

(unsigned int) tv.tv_sec);

err_invalid:

err_read:

rtc_class_close(rtc);

err_open:

rtc_hctosys_ret = err;

return err;

}

late_initcall(rtc_hctosys);

4. 时间的更新

xtime一旦初始化完成后，timekeeper就开始独立于RTC，利用自身关联的clocksource进行时间的更新操作，根据内核的配置项的不同，更新时间的操作发生的频度也不尽相同，如果没有配置NO_HZ选项，通常每个tick的定时中断周期，do_timer会被调用一次，相反，如果配置了NO_HZ选项，可能会在好几个tick后，do_timer才会被调用一次，当然传入的参数是本次更新离上一次更新时相隔了多少个tick周期，系统会保证在clocksource的max_idle_ns时间内调用do_timer，以防止clocksource的溢出：

* The 64-bit jiffies value is not atomic - you MUST NOT read it

* without sampling the sequence number in xtime_lock.

* jiffies is defined in the linker script...

void do_timer(unsigned long ticks)

{

jiffies_64 += ticks;

update_wall_time();

calc_global_load(ticks);

}

在do_timer中，jiffies_64变量被相应地累加，然后在update_wall_time中完成xtime等时间的更新操作，更新时间的核心操作就是读取关联clocksource的计数值，累加到xtime等字段中，其中还设计ntp时间的调整等代码，详细的代码就不贴了。

5. 获取时间

timekeeper提供了一系列的接口用于获取各种时间信息。

void getboottime(struct timespec *ts); 获取系统启动时刻的实时时间

void get_monotonic_boottime(struct timespec *ts); 获取系统启动以来所经过的时间，包含休眠时间

ktime_t ktime_get_boottime(void); 获取系统启动以来所经过的c时间，包含休眠时间，返回ktime类型

ktime_t ktime_get(void); 获取系统启动以来所经过的c时间，不包含休眠时间，返回ktime类型

void ktime_get_ts(struct timespec *ts) ; 获取系统启动以来所经过的c时间，不包含休眠时间，返回timespec结构

unsigned long get_seconds(void); 返回xtime中的秒计数值

struct timespec current_kernel_time(void); 返回内核最后一次更新的xtime时间，不累计最后一次更新至今clocksource的计数值

void getnstimeofday(struct timespec *ts); 获取当前时间，返回timespec结构

void do_gettimeofday(struct timeval *tv); 获取当前时间，返回timeval结构

查看评论

2楼 bingqingsuimeng 2012-12-14 16:01发表 [回复] [引用] [举报]

上面不是说xtime不是纳秒级别的吗？那么它的更新在do_timer中是如何进行纳秒级的更新的？是根据一段时间的统计估算吗？

Re: DroidPhone 2012-12-14 18:33发表 [回复] [引用] [举报]

回复bingqingsuimeng：xtime保存的是最后一次更新的时间，在这一刻它的精度是纳秒级的。实际上，获取时间是通过do_gettimeofday函数，它会返回xtime再加上离上次更新到当前时刻的纳秒数时间差（通过clocksource）。

1楼 zcf19871112 2012-09-20 10:20发表 [回复] [引用] [举报]

楼主，之前您分析ALSA时，画UML图用的是什么软件？

Re: DroidPhone 2012-09-20 10:24发表 [回复] [引用] [举报]

回复zcf19871112：很多朋友问过这个问题，在这里再说一次，我是用的是Enterprise Architect。

4. Linux时间子系统之四：定时器的引擎：clock_event_device

早期的内核版本中，进程的调度基于一个称之为tick的时钟滴答，通常使用时钟中断来定时地产生tick信号，每次tick定时中断都会进行进程的统计和调度，并对tick进行计数，记录在一个jiffies变量中，定时器的设计也是基于jiffies。这时候的内核代码中，几乎所有关于时钟的操作都是在machine级的代码中实现，很多公共的代码要在每个平台上重复实现。随后，随着通用时钟框架的引入，内核需要支持高精度的定时器，为此，通用时间框架为定时器硬件定义了一个标准的接口：clock_event_device，machine级的代码只要按这个标准接口实现相应的硬件控制功能，剩下的与平台无关的特性则统一由通用时间框架层来实现。

/*****************************************************************************************************/

声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！

/*****************************************************************************************************/

1. 时钟事件软件架构

本系列文章的第一节中，我们曾经讨论了时钟源设备：clocksource，现在又来一个时钟事件设备：clock_event_device，它们有何区别？看名字，好像都是给系统提供时钟的设备，实际上，clocksource不能被编程，没有产生事件的能力，它主要被用于timekeeper来实现对真实时间进行精确的统计，而clock_event_device则是可编程的，它可以工作在周期触发或单次触发模式，系统可以对它进行编程，以确定下一次事件触发的时间，clock_event_device主要用于实现普通定时器和高精度定时器，同时也用于产生tick事件，供给进程调度子系统使用。时钟事件设备与通用时间框架中的其他模块的关系如下图所示：

图1.1 clock_event_device软件架构

与clocksource一样，系统中可以存在多个clock_event_device，系统会根据它们的精度和能力，选择合适的clock_event_device对系统提供时钟事件服务。在smp系统中，为了减少处理器间的通信开销，基本上每个cpu都会具备一个属于自己的本地clock_event_device，独立地为该cpu提供时钟事件服务，smp中的每个cpu基于本地的clock_event_device，建立自己的tick_device，普通定时器和高精度定时器。

在软件架构上看，clock_event_device被分为了两层，与硬件相关的被放在了machine层，而与硬件无关的通用代码则被集中到了通用时间框架层，这符合内核对软件的设计需求，平台的开发者只需实现平台相关的接口即可，无需关注复杂的上层时间框架。

tick_device是基于clock_event_device的进一步封装，用于代替原有的时钟滴答中断，给内核提供tick事件，以完成进程的调度和进程信息统计，负载平衡和时间更新等操作。

2. 时钟事件设备相关数据结构

2.1 struct clock_event_device

时钟事件设备的核心数据结构是clock_event_device结构，它代表着一个时钟硬件设备，该设备就好像是一个具有事件触发能力（通常就是指中断）的clocksource，它不停地计数，当计数值达到预先编程设定的数值那一刻，会引发一个时钟事件中断，继而触发该设备的事件处理回调函数，以完成对时钟事件的处理。clock_event_device结构的定义如下：

/**

* struct clock_event_device - clock event device descriptor

* @event_handler: Assigned by the framework to be called by the low

* level handler of the event source

* @set_next_event: set next event function using a clocksource delta

* @set_next_ktime: set next event function using a direct ktime value

* @next_event: local storage for the next event in oneshot mode

* @max_delta_ns: maximum delta value in ns

* @min_delta_ns: minimum delta value in ns

* @mult: nanosecond to cycles multiplier

* @shift: nanoseconds to cycles divisor (power of two)

* @mode: operating mode assigned by the management code

* @features: features

* @retries: number of forced programming retries

* @set_mode: set mode function

* @broadcast: function to broadcast events

* @min_delta_ticks: minimum delta value in ticks stored for reconfiguration

* @max_delta_ticks: maximum delta value in ticks stored for reconfiguration

* @name: ptr to clock event name

* @rating: variable to rate clock event devices

* @irq: IRQ number (only for non CPU local devices)

* @cpumask: cpumask to indicate for which CPUs this device works

* @list: list head for the management code

struct clock_event_device {

void (*event_handler)(struct clock_event_device *);

int (*set_next_event)(unsigned long evt,

struct clock_event_device *);

int (*set_next_ktime)(ktime_t expires,

struct clock_event_device *);

ktime_t next_event;

u64 max_delta_ns;

u64 min_delta_ns;

u32 mult;

u32 shift;

enum clock_event_mode mode;

unsigned int features;

unsigned long retries;

void (*broadcast)(const struct cpumask *mask);

void (*set_mode)(enum clock_event_mode mode,

struct clock_event_device *);

unsigned long min_delta_ticks;

unsigned long max_delta_ticks;

const char *name;

int rating;

int irq;

const struct cpumask *cpumask;

struct list_head list;

} ____cacheline_aligned;

event_handler 该字段是一个回调函数指针，通常由通用框架层设置，在时间中断到来时，machine底层的的中断服务程序会调用该回调，框架层利用该回调实现对时钟事件的处理。

set_next_event 设置下一次时间触发的时间，使用类似于clocksource的cycle计数值（离现在的cycle差值）作为参数。

set_next_ktime 设置下一次时间触发的时间，直接使用ktime时间作为参数。

max_delta_ns 可设置的最大时间差，单位是纳秒。

min_delta_ns 可设置的最小时间差，单位是纳秒。

mult shift 与clocksource中的类似，只不过是用于把纳秒转换为cycle。

mode 该时钟事件设备的工作模式，两种主要的工作模式分别是：

CLOCK_EVT_MODE_PERIODIC 周期触发模式，设置后按给定的周期不停地触发事件；

CLOCK_EVT_MODE_ONESHOT 单次触发模式，只在设置好的触发时刻触发一次；

set_mode 函数指针，用于设置时钟事件设备的工作模式。

rating 表示该设备的精度等级。

list 系统中注册的时钟事件设备用该字段挂在全局链表变量clockevent_devices上。

2.2 全局变量clockevent_devices

系统中所有注册的clock_event_device都会挂在该链表下面，它在kernel/time/clockevents.c中定义：

[cpp] view plain copy print ?

static LIST_HEAD(clockevent_devices);

2.3 全局变量clockevents_chain

通用时间框架初始化时会注册一个通知链（NOTIFIER），当系统中的时钟时间设备的状态发生变化时，利用该通知链通知系统的其它模块。

[cpp] view plain copy print ?

/* Notification for clock events */

static RAW_NOTIFIER_HEAD(clockevents_chain);

3. clock_event_device的初始化和注册

每一个machine，都要定义一个自己的machine_desc结构，该结构定义了该machine的一些最基本的特性，其中需要设定一个sys_timer结构指针，machine级的代码负责定义sys_timer结构，sys_timer的声明很简单：

struct sys_timer {

void (*init)(void);

void (*suspend)(void);

void (*resume)(void);

#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET

unsigned long (*offset)(void);

#endif

};

通常，我们至少要定义它的init字段，系统初始化阶段，该init回调会被调用，该init回调函数的主要作用就是完成系统中的clocksource和clock_event_device的硬件初始化工作，以samsung的exynos4为例，在V3.4内核的代码树中，machine_desc的定义如下：

[cpp] view plain copy print ?

MACHINE_START(SMDK4412, "SMDK4412")

/* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */

/* Maintainer: Changhwan Youn <chaos.youn@samsung.com> */

.atag_offset = 0x100,

.init_irq = exynos4_init_irq,

.map_io = smdk4x12_map_io,

.handle_irq = gic_handle_irq,

.init_machine = smdk4x12_machine_init,

.timer = &exynos4_timer,

.restart = exynos4_restart,

MACHINE_END

定义的sys_timer是exynos4_timer，它的定义和init回调定义如下：

[cpp] view plain copy print ?

static void __init exynos4_timer_init(void)

{

if (soc_is_exynos4210())

mct_int_type = MCT_INT_SPI;

else

mct_int_type = MCT_INT_PPI;

exynos4_timer_resources();

exynos4_clocksource_init();

exynos4_clockevent_init();

}

struct sys_timer exynos4_timer = {

.init = exynos4_timer_init,

};

exynos4_clockevent_init函数显然是初始化和注册clock_event_device的合适时机，在这里，它注册了一个rating为250的clock_event_device，并把它指定给cpu0：

[cpp] view plain copy print ?

static struct clock_event_device mct_comp_device = {

.name = "mct-comp",

.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,

.rating = 250,

.set_next_event = exynos4_comp_set_next_event,

.set_mode = exynos4_comp_set_mode,

};

......

static void exynos4_clockevent_init(void)

{

clockevents_calc_mult_shift(&mct_comp_device, clk_rate, 5);

......

mct_comp_device.cpumask = cpumask_of(0);

clockevents_register_device(&mct_comp_device);

setup_irq(EXYNOS4_IRQ_MCT_G0, &mct_comp_event_irq);

}

因为这个阶段其它cpu核尚未开始工作，所以该clock_event_device也只是在启动阶段给系统提供服务，实际上，因为exynos4是一个smp系统，具备2-4个cpu核心，前面说过，smp系统中，通常会使用各个cpu的本地定时器来为每个cpu单独提供时钟事件服务，继续翻阅代码，在系统初始化的后段，kernel_init会被调用，它会调用smp_prepare_cpus，其中会调用percpu_timer_setup函数，在arch/arm/kernel/smp.c中，为每个cpu定义了一个clock_event_device：

[cpp] view plain copy print ?

* Timer (local or broadcast) support

static DEFINE_PER_CPU(struct clock_event_device, percpu_clockevent);

percpu_timer_setup最终会调用exynos4_local_timer_setup函数完成对本地clock_event_device的初始化工作：

static int __cpuinit exynos4_local_timer_setup(struct clock_event_device *evt)

{

......

evt->name = mevt->name;

evt->cpumask = cpumask_of(cpu);

evt->set_next_event = exynos4_tick_set_next_event;

evt->set_mode = exynos4_tick_set_mode;

evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;

evt->rating = 450;

clockevents_calc_mult_shift(evt, clk_rate / (TICK_BASE_CNT + 1), 5);

......

clockevents_register_device(evt);

......

enable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, 0);

......

return 0;

}

由此可见，每个cpu的本地clock_event_device的rating是450，比启动阶段的250要高，显然，之前注册给cpu0的精度要高，系统会用本地clock_event_device替换掉原来分配给cpu0的clock_event_device，至于怎么替换？我们先停一停，到这里我们一直在讨论machine级别的初始化和注册，让我们回过头来，看看框架层的初始化。在继续之前，让我们看看整个clock_event_device的初始化的调用序列图：

图3.1 clock_event_device的系统初始化

由上面的图示可以看出，框架层的初始化步骤很简单，又start_kernel开始，调用tick_init，它位于kernel/time/tick-common.c中，也只是简单地调用clockevents_register_notifier，同时把类型为notifier_block的tick_notifier作为参数传入，回看2.3节，clockevents_register_notifier注册了一个通知链，这样，当系统中的clock_event_device状态发生变化时（新增，删除，挂起，唤醒等等），tick_notifier中的notifier_call字段中设定的回调函数tick_notify就会被调用。接下来start_kernel调用了time_init函数，该函数通常定义在体系相关的代码中，正如前面所讨论的一样，它主要完成machine级别对时钟系统的初始化工作，最终通过clockevents_register_device注册系统中的时钟事件设备，把每个时钟时间设备挂在clockevent_device全局链表上，最后通过clockevent_do_notify触发框架层事先注册好的通知链，其实就是调用了tick_notify函数，我们主要关注CLOCK_EVT_NOTIFY_ADD通知，其它通知请自行参考代码，下面是tick_notify的简化版本：

static int tick_notify(struct notifier_block *nb, unsigned long reason,

void *dev)

{

switch (reason) {

case CLOCK_EVT_NOTIFY_ADD:

return tick_check_new_device(dev);

case CLOCK_EVT_NOTIFY_BROADCAST_ON:

case CLOCK_EVT_NOTIFY_BROADCAST_OFF:

case CLOCK_EVT_NOTIFY_BROADCAST_FORCE:

......

case CLOCK_EVT_NOTIFY_BROADCAST_ENTER:

case CLOCK_EVT_NOTIFY_BROADCAST_EXIT:

......

case CLOCK_EVT_NOTIFY_CPU_DYING:

......

case CLOCK_EVT_NOTIFY_CPU_DEAD:

......

case CLOCK_EVT_NOTIFY_SUSPEND:

......

case CLOCK_EVT_NOTIFY_RESUME:

......

}

return NOTIFY_OK;

}

可见，对于新注册的clock_event_device，会发出CLOCK_EVT_NOTIFY_ADD通知，最终会进入函数：tick_check_new_device，这个函数比对当前cpu所使用的与新注册的clock_event_device之间的特性，如果认为新的clock_event_device更好，则会进行切换工作。下一节将会详细的讨论该函数。到这里，每个cpu已经有了自己的clock_event_device，在这以后，框架层的代码会根据内核的配置项（CONFIG_NO_HZ、CONFIG_HIGH_RES_TIMERS），对注册的clock_event_device进行不同的设置，从而为系统的tick和高精度定时器提供服务，这些内容我们留在本系列的后续文章进行讨论。

4. tick_device

当内核没有配置成支持高精度定时器时，系统的tick由tick_device产生，tick_device其实是clock_event_device的简单封装，它内嵌了一个clock_event_device指针和它的工作模式：

struct tick_device {

struct clock_event_device *evtdev;

enum tick_device_mode mode;

};

在kernel/time/tick-common.c中，定义了一个per-cpu的tick_device全局变量，tick_cpu_device：

* Tick devices

DEFINE_PER_CPU(struct tick_device, tick_cpu_device);

前面曾经说过，当machine的代码为每个cpu注册clock_event_device时，通知回调函数tick_notify会被调用，进而进入tick_check_new_device函数，下面让我们看看该函数如何工作，首先，该函数先判断注册的clock_event_device是否可用于本cpu，然后从per-cpu变量中取出本cpu的tick_device：

static int tick_check_new_device(struct clock_event_device *newdev)

{

......

cpu = smp_processor_id();

if (!cpumask_test_cpu(cpu, newdev->cpumask))

goto out_bc;

td = &per_cpu(tick_cpu_device, cpu);

curdev = td->evtdev;

如果不是本地clock_event_device，会做进一步的判断：如果不能把irq绑定到本cpu，则放弃处理，如果本cpu已经有了一个本地clock_event_device，也放弃处理：

if (!cpumask_equal(newdev->cpumask, cpumask_of(cpu))) {

......

if (!irq_can_set_affinity(newdev->irq))

goto out_bc;

......

if (curdev && cpumask_equal(curdev->cpumask, cpumask_of(cpu)))

goto out_bc;

}

反之，如果本cpu已经有了一个clock_event_device，则根据是否支持单触发模式和它的rating值，决定是否替换原来旧的clock_event_device：

if (curdev) {

if ((curdev->features & CLOCK_EVT_FEAT_ONESHOT) &&

!(newdev->features & CLOCK_EVT_FEAT_ONESHOT))

goto out_bc; // 新的不支持单触发，但旧的支持，所以不能替换

if (curdev->rating >= newdev->rating)

goto out_bc; // 旧的比新的精度高，不能替换

}

在这些判断都通过之后，说明或者来cpu还没有绑定tick_device，或者是新的更好，需要替换：

if (tick_is_broadcast_device(curdev)) {

clockevents_shutdown(curdev);

curdev = NULL;

}

clockevents_exchange_device(curdev, newdev);

tick_setup_device(td, newdev, cpu, cpumask_of(cpu));

上面的tick_setup_device函数负责重新绑定当前cpu的tick_device和新注册的clock_event_device，如果发现是当前cpu第一次注册tick_device，就把它设置为TICKDEV_MODE_PERIODIC模式，如果是替换旧的tick_device，则根据新的tick_device的特性，设置为TICKDEV_MODE_PERIODIC或TICKDEV_MODE_ONESHOT模式。可见，在系统的启动阶段，tick_device是工作在周期触发模式的，直到框架层在合适的时机，才会开启单触发模式，以便支持NO_HZ和HRTIMER。

5. tick事件的处理--最简单的情况

clock_event_device最基本的应用就是实现tick_device，然后给系统定期地产生tick事件，通用时间框架对clock_event_device和tick_device的处理相当复杂，因为涉及配置项：CONFIG_NO_HZ和CONFIG_HIGH_RES_TIMERS的组合，两个配置项就有4种组合，这四种组合的处理都有所不同，所以这里我先只讨论最简单的情况：

CONFIG_NO_HZ == 0;

CONFIG_HIGH_RES_TIMERS == 0;

在这种配置模式下，我们回到上一节的tick_setup_device函数的最后：

if (td->mode == TICKDEV_MODE_PERIODIC)

tick_setup_periodic(newdev, 0);

else

tick_setup_oneshot(newdev, handler, next_event);

因为启动期间，第一个注册的tick_device必然工作在TICKDEV_MODE_PERIODIC模式，所以tick_setup_periodic会设置clock_event_device的事件回调字段event_handler为tick_handle_periodic，工作一段时间后，就算有新的支持TICKDEV_MODE_ONESHOT模式的clock_event_device需要替换，再次进入tick_setup_device函数，tick_setup_oneshot的handler参数也是之前设置的tick_handle_periodic函数，所以我们考察tick_handle_periodic即可：

void tick_handle_periodic(struct clock_event_device *dev)

{

int cpu = smp_processor_id();

ktime_t next;

tick_periodic(cpu);

if (dev->mode != CLOCK_EVT_MODE_ONESHOT)

return;

next = ktime_add(dev->next_event, tick_period);

for (;;) {

if (!clockevents_program_event(dev, next, false))

return;

if (timekeeping_valid_for_hres())

tick_periodic(cpu);

next = ktime_add(next, tick_period);

}

该函数首先调用tick_periodic函数，完成tick事件的所有处理，如果是周期触发模式，处理结束，如果工作在单触发模式，则计算并设置下一次的触发时刻，这里用了一个循环，是为了防止当该函数被调用时，clock_event_device中的计时实际上已经经过了不止一个tick周期，这时候，tick_periodic可能被多次调用，使得jiffies和时间可以被正确地更新。tick_periodic的代码如下：

static void tick_periodic(int cpu)

{

if (tick_do_timer_cpu == cpu) {

write_seqlock(&xtime_lock);

/* Keep track of the next tick event */

tick_next_period = ktime_add(tick_next_period, tick_period);

do_timer(1);

write_sequnlock(&xtime_lock);

}

update_process_times(user_mode(get_irq_regs()));

profile_tick(CPU_PROFILING);

}

如果当前cpu负责更新时间，则通过do_timer进行以下操作：

更新jiffies_64变量；

更新墙上时钟；

每10个tick，更新一次cpu的负载信息；

调用update_peocess_times，完成以下事情：

更新进程的时间统计信息；

触发TIMER_SOFTIRQ软件中断，以便系统处理传统的低分辨率定时器；

检查rcu的callback；

通过scheduler_tick触发调度系统进行进程统计和调度工作；

查看评论

2楼 rabbit200808 2013-05-15 10:55发表 [回复] [引用] [举报]

1、"clocksource不能被编程，没有产生事件的能力，它主要被用于timekeeper来实现对真实时间进行精确的统计" 2、 “时钟事件设备的核心数据结构是clock_event_device结构，它代表着一个时钟硬件设备，该设备就好像是一个具有事件触发能力（通常就是指中断）的clocksource，它不停地计数，当计数值达到预先编程设定的数值那一刻，会引发一个时钟事件中断” 1和2句话是不是前后矛盾了

1楼异乡客 2013-04-21 21:29发表 [回复] [引用] [举报]

不错的文章，这段时间正学习。多谢。

5. Linux时间子系统之五：低分辨率定时器的原理和实现

利用定时器，我们可以设定在未来的某一时刻，触发一个特定的事件。所谓低分辨率定时器，是指这种定时器的计时单位基于jiffies值的计数，也就是说，它的精度只有1/HZ，假如你的内核配置的HZ是1000，那意味着系统中的低分辨率定时器的精度就是1ms。早期的内核版本中，内核并不支持高精度定时器，理所当然只能使用这种低分辨率定时器，我们有时候把这种基于HZ的定时器机制成为时间轮：time wheel。虽然后来出现了高分辨率定时器，但它只是内核的一个可选配置项，所以直到目前最新的内核版本，这种低分辨率定时器依然被大量地使用着。
/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！
/*****************************************************************************************************/

1. 定时器的使用方法

在讨论定时器的实现原理之前，我们先看看如何使用定时器。要在内核编程中使用定时器，首先我们要定义一个time_list结构，该结构在include/linux/timer.h中定义：

struct timer_list {

* All fields that change during normal runtime grouped to the

* same cacheline

struct list_head entry;

unsigned long expires;

struct tvec_base *base;

void (*function)(unsigned long);

unsigned long data;

int slack;

......

};

entry 字段用于把一组定时器组成一个链表，至于内核如何对定时器进行分组，我们会在后面进行解释。

expires 字段指出了该定时器的到期时刻，也就是期望定时器到期时刻的jiffies计数值。

base 每个cpu拥有一个自己的用于管理定时器的tvec_base结构，该字段指向该定时器所属的cpu所对应tvec_base结构。

function 字段是一个函数指针，定时器到期时，系统将会调用该回调函数，用于响应该定时器的到期事件。

data 该字段用于上述回调函数的参数。

slack 对有些对到期时间精度不太敏感的定时器，到期时刻允许适当地延迟一小段时间，该字段用于计算每次延迟的HZ数。

要定义一个timer_list，我们可以使用静态和动态两种办法，静态方法使用DEFINE_TIMER宏：

#define DEFINE_TIMER(_name, _function, _expires, _data)

该宏将得到一个名字为_name，并分别用_function,_expires,_data参数填充timer_list的相关字段。

如果要使用动态的方法，则可以自己声明一个timer_list结构，然后手动初始化它的各个字段：

struct timer_list timer;

......

init_timer(&timer);

timer.function = _function;

timer.expires = _expires;

timer.data = _data;

要激活一个定时器，我们只要调用add_timer即可：

add_timer(&timer);

要修改定时器的到期时间，我们只要调用mod_timer即可：

mod_timer(&timer, jiffies+50);

要移除一个定时器，我们只要调用del_timer即可：

del_timer(&timer);

定时器系统还提供了以下这些API供我们使用：

void add_timer_on(struct timer_list *timer, int cpu); // 在指定的cpu上添加定时器

int mod_timer_pending(struct timer_list *timer, unsigned long expires); // 只有当timer已经处在激活状态时，才修改timer的到期时刻

int mod_timer_pinned(struct timer_list *timer, unsigned long expires); // 当

void set_timer_slack(struct timer_list *time, int slack_hz); // 设定timer允许的到期时刻的最大延迟，用于对精度不敏感的定时器

int del_timer_sync(struct timer_list *timer); // 如果该timer正在被处理中，则等待timer处理完成才移除该timer

2. 定时器的软件架构

低分辨率定时器是基于HZ来实现的，也就是说，每个tick周期，都有可能有定时器到期，关于tick如何产生，请参考：Linux时间子系统之四：定时器的引擎：clock_event_device。系统中有可能有成百上千个定时器，难道在每个tick中断中遍历一下所有的定时器，检查它们是否到期？内核当然不会使用这么笨的办法，它使用了一个更聪明的办法：按定时器的到期时间对定时器进行分组。因为目前的多核处理器使用越来越广泛，连智能手机的处理器动不动就是4核心，内核对多核处理器有较好的支持，低分辨率定时器在实现时也充分地考虑了多核处理器的支持和优化。为了较好地利用cache line，也为了避免cpu之间的互锁，内核为多核处理器中的每个cpu单独分配了管理定时器的相关数据结构和资源，每个cpu独立地管理属于自己的定时器。

2.1 定时器的分组

首先，内核为每个cpu定义了一个tvec_base结构指针：

static DEFINE_PER_CPU(struct tvec_base *, tvec_bases) = &boot_tvec_bases;

tvec_base结构的定义如下：

struct tvec_base {

spinlock_t lock;

struct timer_list *running_timer;

unsigned long timer_jiffies;

unsigned long next_timer;

struct tvec_root tv1;

struct tvec tv2;

struct tvec tv3;

struct tvec tv4;

struct tvec tv5;

} ____cacheline_aligned;

running_timer 该字段指向当前cpu正在处理的定时器所对应的timer_list结构。

timer_jiffies 该字段表示当前cpu定时器所经历过的jiffies数，大多数情况下，该值和jiffies计数值相等，当cpu的idle状态连续持续了多个jiffies时间时，当退出idle状态时，jiffies计数值就会大于该字段，在接下来的tick中断后，定时器系统会让该字段的值追赶上jiffies值。

next_timer 该字段指向该cpu下一个即将到期的定时器。

tv1--tv5 这5个字段用于对定时器进行分组，实际上，tv1--tv5都是一个链表数组，其中tv1的数组大小为TVR_SIZE， tv2 tv3 tv4 tv5的数组大小为TVN_SIZE，根据CONFIG_BASE_SMALL配置项的不同，它们有不同的大小：

[cpp] view plain copy print ?

#define TVN_BITS (CONFIG_BASE_SMALL ? 4 : 6)

#define TVR_BITS (CONFIG_BASE_SMALL ? 6 : 8)

#define TVN_SIZE (1 << TVN_BITS)

#define TVR_SIZE (1 << TVR_BITS)

#define TVN_MASK (TVN_SIZE - 1)

#define TVR_MASK (TVR_SIZE - 1)

struct tvec {

struct list_head vec[TVN_SIZE];

};

struct tvec_root {

struct list_head vec[TVR_SIZE];

};

#define TVN_BITS (CONFIG_BASE_SMALL ? 4 : 6)

#define TVR_BITS (CONFIG_BASE_SMALL ? 6 : 8)

#define TVN_SIZE (1 << TVN_BITS)

#define TVR_SIZE (1 << TVR_BITS)

#define TVN_MASK (TVN_SIZE - 1)

#define TVR_MASK (TVR_SIZE - 1)

struct tvec {

struct list_head vec[TVN_SIZE];

};

struct tvec_root {

struct list_head vec[TVR_SIZE];

};

默认情况下，没有使能CONFIG_BASE_SMALL，TVR_SIZE的大小是256，TVN_SIZE的大小则是64，当需要节省内存空间时，也可以使能CONFIG_BASE_SMALL，这时TVR_SIZE的大小是64，TVN_SIZE的大小则是16，以下的讨论我都是基于没有使能CONFIG_BASE_SMALL的情况。当有一个新的定时器要加入时，系统根据定时器到期的jiffies值和timer_jiffies字段的差值来决定该定时器被放入tv1至tv5中的哪一个数组中，最终，系统中所有的定时器的组织结构如下图所示：

图 2.1.1 定时器在系统中的组织结构

2.2 定时器的添加

要加入一个新的定时器，我们可以通过api函数add_timer或mod_timer来完成，最终的工作会交由internal_add_timer函数来处理。该函数按以下步骤进行处理：

计算定时器到期时间和所属cpu的tvec_base结构中的timer_jiffies字段的差值，记为idx；

根据idx的值，选择该定时器应该被放到tv1--tv5中的哪一个链表数组中，可以认为tv1-tv5分别占据一个32位数的不同比特位，tv1占据最低的8位，tv2占据紧接着的6位，然后tv3再占位，以此类推，最高的6位分配给tv5。最终的选择规则如下表所示：

链表数组	idx范围
tv1	0-255(2^8)
tv2	256--16383(2^14)
tv3	16384--1048575(2^20)
tv4	1048576--67108863(2^26)
tv5	67108864--4294967295(2^32)

确定链表数组后，接着要确定把该定时器放入数组中的哪一个链表中，如果时间差idx小于256，按规则要放入tv1中，因为tv1包含了256个链表，所以可以简单地使用timer_list.expires的低8位作为数组的索引下标，把定时器链接到tv1中相应的链表中即可。如果时间差idx的值在256--18383之间，则需要把定时器放入tv2中，同样的，使用timer_list.expires的8--14位作为数组的索引下标，把定时器链接到tv2中相应的链表中,。定时器要加入tv3 tv4 tv5使用同样的原理。经过这样分组后的定时器，在后续的tick事件中，系统可以很方便地定位并取出相应的到期定时器进行处理。以上的讨论都体现在internal_add_timer的代码中：

static void internal_add_timer(struct tvec_base *base, struct timer_list *timer)

{

unsigned long expires = timer->expires;

unsigned long idx = expires - base->timer_jiffies;

struct list_head *vec;

if (idx < TVR_SIZE) {

int i = expires & TVR_MASK;

vec = base->tv1.vec + i;

} else if (idx < 1 << (TVR_BITS + TVN_BITS)) {

int i = (expires >> TVR_BITS) & TVN_MASK;

vec = base->tv2.vec + i;

} else if (idx < 1 << (TVR_BITS + 2 * TVN_BITS)) {

int i = (expires >> (TVR_BITS + TVN_BITS)) & TVN_MASK;

vec = base->tv3.vec + i;

} else if (idx < 1 << (TVR_BITS + 3 * TVN_BITS)) {

int i = (expires >> (TVR_BITS + 2 * TVN_BITS)) & TVN_MASK;

vec = base->tv4.vec + i;

} else if ((signed long) idx < 0) {

......

} else {

......

i = (expires >> (TVR_BITS + 3 * TVN_BITS)) & TVN_MASK;

vec = base->tv5.vec + i;

}

list_add_tail(&timer->entry, vec);

}

2.2 定时器的到期处理

经过2.1节的处理后，系统中的定时器按到期时间有规律地放置在tv1--tv5各个链表数组中，其中tv1中放置着在接下来的256个jiffies即将到期的定时器列表，需要注意的是，并不是tv1.vec[0]中放置着马上到期的定时器列表，tv1.vec[1]中放置着将在jiffies+1到期的定时器列表。因为base.timer_jiffies的值一直在随着系统的运行而动态地增加，原则上是每个tick事件会加1，base.timer_jiffies代表者该cpu定时器系统当前时刻，定时器也是动态地加入头256个链表tv1中，按2.1节的讨论，定时器加入tv1中使用的下标索引是定时器到期时间expires的低8位，所以假设当前的base.timer_jiffies值是0x34567826，则马上到期的定时器是在tv1.vec[0x26]中，如果这时候系统加入一个在jiffies值0x34567828到期的定时器，他将会加入到tv1.vec[0x28]中，运行两个tick后，base.timer_jiffies的值会变为0x34567828，很显然，在每次tick事件中，定时器系统只要以base.timer_jiffies的低8位作为索引，取出tv1中相应的链表，里面正好包含了所有在该jiffies值到期的定时器列表。

那什么时候处理tv2--tv5中的定时器？每当base.timer_jiffies的低8位为0值时，这表明base.timer_jiffies的第8-13位有进位发生，这6位正好代表着tv2，这时只要按base.timer_jiffies的第8-13位的值作为下标，移出tv2中对应的定时器链表，然后用internal_add_timer把它们从新加入到定时器系统中来，因为这些定时器一定会在接下来的256个tick期间到期，所以它们肯定会被加入到tv1数组中，这样就完成了tv2往tv1迁移的过程。同样地，当base.timer_jiffies的第8-13位为0时，这表明base.timer_jiffies的第14-19位有进位发生，这6位正好代表着tv3，按base.timer_jiffies的第14-19位的值作为下标，移出tv3中对应的定时器链表，然后用internal_add_timer把它们从新加入到定时器系统中来，显然它们会被加入到tv2中，从而完成tv3到tv2的迁移，tv4，tv5的处理可以以此作类推。具体迁移的代码如下，参数index为事先计算好的高一级tv的需要迁移的数组索引：

static int cascade(struct tvec_base *base, struct tvec *tv, int index)

{

/* cascade all the timers from tv up one level */

struct timer_list *timer, *tmp;

struct list_head tv_list;

list_replace_init(tv->vec + index, &tv_list); // 移除需要迁移的链表

* We are removing _all_ timers from the list, so we

* don't have to detach them individually.

list_for_each_entry_safe(timer, tmp, &tv_list, entry) {

BUG_ON(tbase_get_base(timer->base) != base);

// 重新加入到定时器系统中，实际上将会迁移到下一级的tv数组中

internal_add_timer(base, timer);

}

return index;

}

每个tick事件到来时，内核会在tick定时中断处理期间激活定时器软中断：TIMER_SOFTIRQ，关于软件中断，请参考另一篇博文：Linux中断（interrupt）子系统之五：软件中断（softIRQ。TIMER_SOFTIRQ的执行函数是__run_timers，它实现了本节讨论的逻辑，取出tv1中到期的定时器，执行定时器的回调函数，由此可见，低分辨率定时器的回调函数是执行在软件中断上下文中的，这点在写定时器的回调函数时需要注意。__run_timers的代码如下：

static inline void __run_timers(struct tvec_base *base)

{

struct timer_list *timer;

spin_lock_irq(&base->lock);

/* 同步jiffies，在NO_HZ情况下，base->timer_jiffies可能落后不止一个tick */

while (time_after_eq(jiffies, base->timer_jiffies)) {

struct list_head work_list;

struct list_head *head = &work_list;

/* 计算到期定时器链表在tv1中的索引 */

int index = base->timer_jiffies & TVR_MASK;

* /* tv2--tv5定时器列表迁移处理 */

if (!index &&

(!cascade(base, &base->tv2, INDEX(0))) &&

(!cascade(base, &base->tv3, INDEX(1))) &&

!cascade(base, &base->tv4, INDEX(2)))

cascade(base, &base->tv5, INDEX(3));

/* 该cpu定时器系统运行时间递增一个tick */

++base->timer_jiffies;

/* 取出到期的定时器链表 */

list_replace_init(base->tv1.vec + index, &work_list);

/* 遍历所有的到期定时器 */

while (!list_empty(head)) {

void (*fn)(unsigned long);

unsigned long data;

timer = list_first_entry(head, struct timer_list,entry);

fn = timer->function;

data = timer->data;

timer_stats_account_timer(timer);

base->running_timer = timer; /* 标记正在处理的定时器 */

detach_timer(timer, 1);

spin_unlock_irq(&base->lock);

call_timer_fn(timer, fn, data); /* 调用定时器的回调函数 */

spin_lock_irq(&base->lock);

}

base->running_timer = NULL;

spin_unlock_irq(&base->lock);

}

通过上面的讨论，我们可以发现，内核的低分辨率定时器的实现非常精妙，既实现了大量定时器的管理，又实现了快速的O(1)查找到期定时器的能力，利用巧妙的数组结构，使得只需在间隔256个tick时间才处理一次迁移操作，5个数组就好比是5个齿轮，它们随着base->timer_jifffies的增长而不停地转动，每次只需处理第一个齿轮的某一个齿节，低一级的齿轮转动一圈，高一级的齿轮转动一个齿，同时自动把即将到期的定时器迁移到上一个齿轮中，所以低分辨率定时器通常又被叫做时间轮：time wheel。事实上，它的实现是一个很好的空间换时间软件算法。

3. 定时器软件中断

系统初始化时，start_kernel会调用定时器系统的初始化函数init_timers：

void __init init_timers(void)

{

int err = timer_cpu_notify(&timers_nb, (unsigned long)CPU_UP_PREPARE,

(void *)(long)smp_processor_id());

init_timer_stats();

BUG_ON(err != NOTIFY_OK);

register_cpu_notifier(&timers_nb); /* 注册cpu notify，以便在hotplug时在cpu之间进行定时器的迁移 */

open_softirq(TIMER_SOFTIRQ, run_timer_softirq);

}

可见，open_softirq把run_timer_softirq注册为TIMER_SOFTIRQ的处理函数，另外，当cpu的每个tick事件到来时，在事件处理中断中，update_process_times会被调用，该函数会进一步调用run_local_timers，run_local_timers会触发TIMER_SOFTIRQ软中断：

void run_local_timers(void)

{

hrtimer_run_queues();

raise_softirq(TIMER_SOFTIRQ);

}

TIMER_SOFTIRQ的处理函数是run_timer_softirq：

static void run_timer_softirq(struct softirq_action *h)

{

struct tvec_base *base = __this_cpu_read(tvec_bases);

hrtimer_run_pending();

if (time_after_eq(jiffies, base->timer_jiffies))

__run_timers(base);

}

好啦，终于看到__run_timers函数了，2.2节已经介绍过，正是这个函数完成了对到期定时器的处理工作，也完成了时间轮的不停转动。

6. Linux时间子系统之六：高精度定时器（HRTIMER）的原理和实现

上一篇文章，我介绍了传统的低分辨率定时器的实现原理。而随着内核的不断演进，大牛们已经对这种低分辨率定时器的精度不再满足，而且，硬件也在不断地发展，系统中的定时器硬件的精度也越来越高，这也给高分辨率定时器的出现创造了条件。内核从2.6.16开始加入了高精度定时器架构。在实现方式上，内核的高分辨率定时器的实现代码几乎没有借用低分辨率定时器的数据结构和代码，内核文档给出的解释主要有以下几点：

低分辨率定时器的代码和jiffies的关系太过紧密，并且默认按32位进行设计，并且它的代码已经经过长时间的优化，目前的使用也是没有任何错误，如果硬要基于它来实现高分辨率定时器，势必会打破原有的时间轮概念，并且会引入一大堆#if--#else判断；

虽然大部分时间里，时间轮可以实现O(1)时间复杂度，但是当有进位发生时，不可预测的O(N)定时器级联迁移时间，这对于低分辨率定时器来说问题不大，可是它大大地影响了定时器的精度；

低分辨率定时器几乎是为“超时”而设计的，并为此对它进行了大量的优化，对于这些以“超时”为目的而使用定时器，它们大多数期望在超时到来之前获得正确的结果，然后删除定时器，精确时间并不是它们主要的目的，例如网络通信、设备IO等等。

为此，内核为高精度定时器重新设计了一套软件架构，它可以为我们提供纳秒级的定时精度，以满足对精确时间有迫切需求的应用程序或内核驱动，例如多媒体应用，音频设备的驱动程序等等。以下的讨论用hrtimer(high resolution timer)表示高精度定时器。

1. 如何组织hrtimer？

我们知道，低分辨率定时器使用5个链表数组来组织timer_list结构，形成了著名的时间轮概念，对于高分辨率定时器，我们期望组织它们的数据结构至少具备以下条件：

稳定而且快速的查找能力；

快速地插入和删除定时器的能力；

排序功能；

内核的开发者考察了多种数据结构，例如基数树、哈希表等等，最终他们选择了红黑树（rbtree）来组织hrtimer，红黑树已经以库的形式存在于内核中，并被成功地使用在内存管理子系统和文件系统中，随着系统的运行，hrtimer不停地被创建和销毁，新的hrtimer按顺序被插入到红黑树中，树的最左边的节点就是最快到期的定时器，内核用一个hrtimer结构来表示一个高精度定时器：

/**

* struct hrtimer - the basic hrtimer structure

* @node: timerqueue node, which also manages node.expires,

* the absolute expiry time in the hrtimers internal

* representation. The time is related to the clock on

* which the timer is based. Is setup by adding

* slack to the _softexpires value. For non range timers

* identical to _softexpires.

* @_softexpires: the absolute earliest expiry time of the hrtimer.

* The time which was given as expiry time when the timer

* was armed.

* @function: timer expiry callback function

* @base: pointer to the timer base (per cpu and per clock)

* @state: state information (See bit values above)

* @start_site: timer statistics field to store the site where the timer

* was started

* @start_comm: timer statistics field to store the name of the process which

* started the timer

* @start_pid: timer statistics field to store the pid of the task which

* started the timer

* The hrtimer structure must be initialized by hrtimer_init()

struct hrtimer {

struct timerqueue_node node;

ktime_t _softexpires;

enum hrtimer_restart (*function)(struct hrtimer *);

struct hrtimer_clock_base *base;

unsigned long state;

#ifdef CONFIG_TIMER_STATS

int start_pid;

void *start_site;

char start_comm[16];

#endif

};

定时器的到期时间用ktime_t来表示，_softexpires字段记录了时间，定时器一旦到期，function字段指定的回调函数会被调用，该函数的返回值为一个枚举值，它决定了该hrtimer是否需要被重新激活：

enum hrtimer_restart {

HRTIMER_NORESTART, /* Timer is not restarted */

HRTIMER_RESTART, /* Timer must be restarted */

};

state字段用于表示hrtimer当前的状态，有几下几种位组合：

#define HRTIMER_STATE_INACTIVE 0x00 // 定时器未激活

#define HRTIMER_STATE_ENQUEUED 0x01 // 定时器已经被排入红黑树中

#define HRTIMER_STATE_CALLBACK 0x02 // 定时器的回调函数正在被调用

#define HRTIMER_STATE_MIGRATE 0x04 // 定时器正在CPU之间做迁移

hrtimer的到期时间可以基于以下几种时间基准系统：

enum hrtimer_base_type {

HRTIMER_BASE_MONOTONIC, // 单调递增的monotonic时间，不包含休眠时间

HRTIMER_BASE_REALTIME, // 平常使用的墙上真实时间

HRTIMER_BASE_BOOTTIME, // 单调递增的boottime，包含休眠时间

HRTIMER_MAX_CLOCK_BASES, // 用于后续数组的定义

};

和低分辨率定时器一样，处于效率和上锁的考虑，每个cpu单独管理属于自己的hrtimer，为此，专门定义了一个结构hrtimer_cpu_base：

[cpp] view plain copy print ?

struct hrtimer_cpu_base {

......

struct hrtimer_clock_base clock_base[HRTIMER_MAX_CLOCK_BASES];

};

其中，clock_base数组为每种时间基准系统都定义了一个hrtimer_clock_base结构，它的定义如下：

[cpp] view plain copy print ?

struct hrtimer_clock_base {

struct hrtimer_cpu_base *cpu_base; // 指向所属cpu的hrtimer_cpu_base结构

......

struct timerqueue_head active; // 红黑树，包含了所有使用该时间基准系统的hrtimer

ktime_t resolution; // 时间基准系统的分辨率

ktime_t (*get_time)(void); // 获取该基准系统的时间函数

ktime_t softirq_time;// 当用jiffies

ktime_t offset; //

};

active字段是一个timerqueue_head结构，它实际上是对rbtree的进一步封装：

[cpp] view plain copy print ?

struct timerqueue_node {

struct rb_node node; // 红黑树的节点

ktime_t expires; // 该节点代表队hrtimer的到期时间，与hrtimer结构中的_softexpires稍有不同

};

struct timerqueue_head {

struct rb_root head; // 红黑树的根节点

struct timerqueue_node *next; // 该红黑树中最早到期的节点，也就是最左下的节点

};

timerqueue_head结构在红黑树的基础上，增加了一个next字段，用于保存树中最先到期的定时器节点，实际上就是树的最左下方的节点，有了next字段，当到期事件到来时，系统不必遍历整个红黑树，只要取出next字段对应的节点进行处理即可。timerqueue_node用于表示一个hrtimer节点，它在标准红黑树节点rb_node的基础上增加了expires字段，该字段和hrtimer中的_softexpires字段一起，设定了hrtimer的到期时间的一个范围，hrtimer可以在hrtimer._softexpires至timerqueue_node.expires之间的任何时刻到期，我们也称timerqueue_node.expires为硬过期时间(hard)，意思很明显：到了此时刻，定时器一定会到期，有了这个范围可以选择，定时器系统可以让范围接近的多个定时器在同一时刻同时到期，这种设计可以降低进程频繁地被hrtimer进行唤醒。经过以上的讨论，我们可以得出以下的图示，它表明了每个cpu上的hrtimer是如何被组织在一起的：

图 1.1 每个cpu的hrtimer组织结构

总结一下：

每个cpu有一个hrtimer_cpu_base结构；

hrtimer_cpu_base结构管理着3种不同的时间基准系统的hrtimer，分别是：实时时间，启动时间和单调时间；

每种时间基准系统通过它的active字段（timerqueue_head结构指针），指向它们各自的红黑树；

红黑树上，按到期时间进行排序，最先到期的hrtimer位于最左下的节点，并被记录在active.next字段中；

三种时间基准的最先到期时间可能不同，所以，它们之中最先到期的时间被记录在hrtimer_cpu_base的expires_next字段中。

2. hrtimer如何运转

hrtimer的实现需要一定的硬件基础，它的实现依赖于我们前几章介绍的timekeeper和clock_event_device，如果你对timekeeper和clock_event_device不了解请参考以下文章：Linux时间子系统之三：时间的维护者：timekeeper，Linux时间子系统之四：定时器的引擎：clock_event_device。hrtimer系统需要通过timekeeper获取当前的时间，计算与到期时间的差值，并根据该差值，设定该cpu的tick_device（clock_event_device）的下一次的到期时间，时间一到，在clock_event_device的事件回调函数中处理到期的hrtimer。现在你或许有疑问：前面在介绍clock_event_device时，我们知道，每个cpu有自己的tick_device，通常用于周期性地产生进程调度和时间统计的tick事件，这里又说要用tick_device调度hrtimer系统，通常cpu只有一个tick_device，那他们如何协调工作？这个问题也一度困扰着我，如果再加上NO_HZ配置带来tickless特性，你可能会更晕。这里我们先把这个疑问放下，我将在后面的章节中来讨论这个问题，现在我们只要先知道，一旦开启了hrtimer，tick_device所关联的clock_event_device的事件回调函数会被修改为：hrtimer_interrupt，并且会被设置成工作于CLOCK_EVT_MODE_ONESHOT单触发模式。

2.1 添加一个hrtimer

要添加一个hrtimer，系统提供了一些api供我们使用，首先我们需要定义一个hrtimer结构的实例，然后用hrtimer_init函数对它进行初始化，它的原型如下：

[cpp] view plain copy print ?

void hrtimer_init(struct hrtimer *timer, clockid_t which_clock,

enum hrtimer_mode mode);

which_clock可以是CLOCK_REALTIME、CLOCK_MONOTONIC、CLOCK_BOOTTIME中的一种，mode则可以是相对时间HRTIMER_MODE_REL，也可以是绝对时间HRTIMER_MODE_ABS。设定回调函数：

timer.function = hr_callback;

如果定时器无需指定一个到期范围，可以在设定回调函数后直接使用hrtimer_start激活该定时器：

int hrtimer_start(struct hrtimer *timer, ktime_t tim,

const enum hrtimer_mode mode);

如果需要指定到期范围，则可以使用hrtimer_start_range_ns激活定时器：

hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim,

unsigned long range_ns, const enum hrtimer_mode mode);

要取消一个hrtimer，使用hrtimer_cancel：

int hrtimer_cancel(struct hrtimer *timer);

以下两个函数用于推后定时器的到期时间：

extern u64

hrtimer_forward(struct hrtimer *timer, ktime_t now, ktime_t interval);

/* Forward a hrtimer so it expires after the hrtimer's current now */

static inline u64 hrtimer_forward_now(struct hrtimer *timer,

ktime_t interval)

{

return hrtimer_forward(timer, timer->base->get_time(), interval);

}

以下几个函数用于获取定时器的当前状态：

static inline int hrtimer_active(const struct hrtimer *timer)

{

return timer->state != HRTIMER_STATE_INACTIVE;

}

static inline int hrtimer_is_queued(struct hrtimer *timer)

{

return timer->state & HRTIMER_STATE_ENQUEUED;

}

static inline int hrtimer_callback_running(struct hrtimer *timer)

{

return timer->state & HRTIMER_STATE_CALLBACK;

}

hrtimer_init最终会进入__hrtimer_init函数，该函数的主要目的是初始化hrtimer的base字段，同时初始化作为红黑树的节点的node字段：

static void __hrtimer_init(struct hrtimer *timer, clockid_t clock_id,

enum hrtimer_mode mode)

{

struct hrtimer_cpu_base *cpu_base;

int base;

memset(timer, 0, sizeof(struct hrtimer));

cpu_base = &__raw_get_cpu_var(hrtimer_bases);

if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS)

clock_id = CLOCK_MONOTONIC;

base = hrtimer_clockid_to_base(clock_id);

timer->base = &cpu_base->clock_base[base];

timerqueue_init(&timer->node);

......

}

hrtimer_start和hrtimer_start_range_ns最终会把实际的工作交由__hrtimer_start_range_ns来完成：

int __hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim,

unsigned long delta_ns, const enum hrtimer_mode mode,

int wakeup)

{

......

/* 取得hrtimer_clock_base指针 */

base = lock_hrtimer_base(timer, &flags);

/* 如果已经在红黑树中，先移除它: */

ret = remove_hrtimer(timer, base); ......

/* 如果是相对时间，则需要加上当前时间，因为内部是使用绝对时间 */

if (mode & HRTIMER_MODE_REL) {

tim = ktime_add_safe(tim, new_base->get_time());

......

}

/* 设置到期的时间范围 */

hrtimer_set_expires_range_ns(timer, tim, delta_ns);

......

/* 把hrtime按到期时间排序，加入到对应时间基准系统的红黑树中 */

/* 如果该定时器的是最早到期的，将会返回true */

leftmost = enqueue_hrtimer(timer, new_base);

* Only allow reprogramming if the new base is on this CPU.

* (it might still be on another CPU if the timer was pending)

* XXX send_remote_softirq() ?

* 定时器比之前的到期时间要早，所以需要重新对tick_device进行编程，重新设定的的到期时间

if (leftmost && new_base->cpu_base == &__get_cpu_var(hrtimer_bases))

hrtimer_enqueue_reprogram(timer, new_base, wakeup);

unlock_hrtimer_base(timer, &flags);

return ret;

}

2.2 hrtimer的到期处理

高精度定时器系统有3个入口可以对到期定时器进行处理，它们分别是：

没有切换到高精度模式时，在每个jiffie的tick事件中断中进行查询和处理；

在HRTIMER_SOFTIRQ软中断中进行查询和处理；

切换到高精度模式后，在每个clock_event_device的到期事件中断中进行查询和处理；

低精度模式因为系统并不是一开始就会支持高精度模式，而是在系统启动后的某个阶段，等待所有的条件都满足后，才会切换到高精度模式，当系统还没有切换到高精度模式时，所有的高精度定时器运行在低精度模式下，在每个jiffie的tick事件中断中进行到期定时器的查询和处理，显然这时候的精度和低分辨率定时器是一样的（HZ级别）。低精度模式下，每个tick事件中断中，hrtimer_run_queues函数会被调用，由它完成定时器的到期处理。hrtimer_run_queues首先判断目前高精度模式是否已经启用，如果已经切换到了高精度模式，什么也不做，直接返回：

void hrtimer_run_queues(void)

{

if (hrtimer_hres_active())

return;

如果hrtimer_hres_active返回false，说明目前处于低精度模式下，则继续处理，它用一个for循环遍历各个时间基准系统，查询每个hrtimer_clock_base对应红黑树的左下节点，判断它的时间是否到期，如果到期，通过__run_hrtimer函数，对到期定时器进行处理，包括：调用定时器的回调函数、从红黑树中移除该定时器、根据回调函数的返回值决定是否重新启动该定时器等等：

for (index = 0; index < HRTIMER_MAX_CLOCK_BASES; index++) {

base = &cpu_base->clock_base[index];

if (!timerqueue_getnext(&base->active))

continue;

if (gettime) {

hrtimer_get_softirq_time(cpu_base);

gettime = 0;

}

raw_spin_lock(&cpu_base->lock);

while ((node = timerqueue_getnext(&base->active))) {

struct hrtimer *timer;

timer = container_of(node, struct hrtimer, node);

if (base->softirq_time.tv64 <=

hrtimer_get_expires_tv64(timer))

break;

__run_hrtimer(timer, &base->softirq_time);

}

raw_spin_unlock(&cpu_base->lock);

}

上面的timerqueue_getnext函数返回红黑树中的左下节点，之所以可以在while循环中使用该函数，是因为__run_hrtimer会在移除旧的左下节点时，新的左下节点会被更新到base->active->next字段中，使得循环可以继续执行，直到没有新的到期定时器为止。

高精度模式切换到高精度模式后，原来给cpu提供tick事件的tick_device（clock_event_device）会被高精度定时器系统接管，它的中断事件回调函数被设置为hrtimer_interrupt，红黑树中最左下的节点的定时器的到期时间被编程到该clock_event_device中，这样每次clock_event_device的中断意味着至少有一个高精度定时器到期。另外，当timekeeper系统中的时间需要修正，或者clock_event_device的到期事件时间被重新编程时，系统会发出HRTIMER_SOFTIRQ软中断，软中断的处理函数run_hrtimer_softirq最终也会调用hrtimer_interrupt函数对到期定时器进行处理，所以在这里我们只要讨论hrtimer_interrupt函数的实现即可。

hrtimer_interrupt函数的前半部分和低精度模式下的hrtimer_run_queues函数完成相同的事情：它用一个for循环遍历各个时间基准系统，查询每个hrtimer_clock_base对应红黑树的左下节点，判断它的时间是否到期，如果到期，通过__run_hrtimer函数，对到期定时器进行处理，所以我们只讨论后半部分，在处理完所有到期定时器后，下一个到期定时器的到期时间保存在变量expires_next中，接下来的工作就是把这个到期时间编程到tick_device中：

void hrtimer_interrupt(struct clock_event_device *dev)

{

......

for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {

......

while ((node = timerqueue_getnext(&base->active))) {

......

if (basenow.tv64 < hrtimer_get_softexpires_tv64(timer)) {

ktime_t expires;

expires = ktime_sub(hrtimer_get_expires(timer),

base->offset);

if (expires.tv64 < expires_next.tv64)

expires_next = expires;

break;

}

__run_hrtimer(timer, &basenow);

}

* Store the new expiry value so the migration code can verify

* against it.

cpu_base->expires_next = expires_next;

raw_spin_unlock(&cpu_base->lock);

/* Reprogramming necessary ? */

if (expires_next.tv64 == KTIME_MAX ||

!tick_program_event(expires_next, 0)) {

cpu_base->hang_detected = 0;

return;

}

如果这时的tick_program_event返回了非0值，表示过期时间已经在当前时间的前面，这通常由以下原因造成：

系统正在被调试跟踪，导致时间在走，程序不走；

定时器的回调函数花了太长的时间；

系统运行在虚拟机中，而虚拟机被调度导致停止运行；

为了避免这些情况的发生，接下来系统提供3次机会，重新执行前面的循环，处理到期的定时器：

raw_spin_lock(&cpu_base->lock);

now = hrtimer_update_base(cpu_base);

cpu_base->nr_retries++;

if (++retries < 3)

goto retry;

如果3次循环后还无法完成到期处理，系统不再循环，转为计算本次总循环的时间，然后把tick_device的到期时间强制设置为当前时间加上本次的总循环时间，不过推后的时间被限制在100ms以内：

delta = ktime_sub(now, entry_time);

if (delta.tv64 > cpu_base->max_hang_time.tv64)

cpu_base->max_hang_time = delta;

* Limit it to a sensible value as we enforce a longer

* delay. Give the CPU at least 100ms to catch up.

if (delta.tv64 > 100 * NSEC_PER_MSEC)

expires_next = ktime_add_ns(now, 100 * NSEC_PER_MSEC);

else

expires_next = ktime_add(now, delta);

tick_program_event(expires_next, 1);

printk_once(KERN_WARNING "hrtimer: interrupt took %llu ns\n",

ktime_to_ns(delta));

}

3. 切换到高精度模式

上面提到，尽管内核配置成支持高精度定时器，但并不是一开始就工作于高精度模式，系统在启动的开始阶段，还是按照传统的模式在运行：tick_device按HZ频率定期地产生tick事件，这时的hrtimer工作在低分辨率模式，到期事件在每个tick事件中断中由hrtimer_run_queues函数处理，同时，在低分辨率定时器（时间轮）的软件中断TIMER_SOFTIRQ中，hrtimer_run_pending会被调用，系统在这个函数中判断系统的条件是否满足切换到高精度模式，如果条件满足，则会切换至高分辨率模式，另外提一下，NO_HZ模式也是在该函数中判断并切换。

void hrtimer_run_pending(void)

{

if (hrtimer_hres_active())

return;

......

if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))

hrtimer_switch_to_hres();

}

因为不管系统是否工作于高精度模式，每个TIMER_SOFTIRQ期间，该函数都会被调用，所以函数一开始先用hrtimer_hres_active判断目前高精度模式是否已经激活，如果已经激活，则说明之前的调用中已经切换了工作模式，不必再次切换，直接返回。hrtimer_hres_active很简单：

DEFINE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases) = {

......

}

static inline int hrtimer_hres_active(void)

{

return __this_cpu_read(hrtimer_bases.hres_active);

}

hrtimer_run_pending函数接着通过tick_check_oneshot_change判断系统是否可以切换到高精度模式，

int tick_check_oneshot_change(int allow_nohz)

{

struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);

if (!test_and_clear_bit(0, &ts->check_clocks))

return 0;

if (ts->nohz_mode != NOHZ_MODE_INACTIVE)

return 0;

if (!timekeeping_valid_for_hres() || !tick_is_oneshot_available())

return 0;

if (!allow_nohz)

return 1;

tick_nohz_switch_to_nohz();

return 0;

}

函数的一开始先判断check_clock标志的第0位是否被置位，如果没有置位，说明系统中没有注册符合要求的时钟事件设备，函数直接返回，check_clock标志由clocksource和clock_event_device系统的notify系统置位，当系统中有更高精度的clocksource被注册和选择后，或者有更精确的支持CLOCK_EVT_MODE_ONESHOT模式的clock_event_device被注册时，通过它们的notify函数，check_clock标志的第0为会置位。

如果tick_sched结构中的nohz_mode字段不是NOHZ_MODE_INACTIVE，表明系统已经切换到其它模式，直接返回。nohz_mode的取值有3种：

NOHZ_MODE_INACTIVE // 未启用NO_HZ模式

NOHZ_MODE_LOWRES // 启用NO_HZ模式，hrtimer工作于低精度模式下

NOHZ_MODE_HIGHRES // 启用NO_HZ模式，hrtimer工作于高精度模式下

接下来的timerkeeping_valid_for_hres判断timekeeper系统是否支持高精度模式，tick_is_oneshot_available判断tick_device是否支持CLOCK_EVT_MODE_ONESHOT模式。如果都满足要求，则继续往下判断。allow_nohz是函数的参数，为true表明可以切换到NOHZ_MODE_LOWRES 模式，函数将进入tick_nohz_switch_to_nohz，切换至NOHZ_MODE_LOWRES 模式，这里我们传入的allow_nohz是表达式：

(!hrtimer_is_hres_enabled())

所以当系统不允许高精度模式时，将会在tick_check_oneshot_change函数内，通过tick_nohz_switch_to_nohz切换至NOHZ_MODE_LOWRES 模式，如果系统允许高精度模式，传入的allow_nohz参数为false，tick_check_oneshot_change函数返回1，回到上面的hrtimer_run_pending函数，hrtimer_switch_to_hres函数将会被调用，已完成切换到NOHZ_MODE_HIGHRES高精度模式。好啦，真正的切换函数找到了，我们看一看它如何切换：

首先，它通过hrtimer_cpu_base中的hres_active字段判断该cpu是否已经切换至高精度模式，如果是则直接返回：

static int hrtimer_switch_to_hres(void)

{

int i, cpu = smp_processor_id();

struct hrtimer_cpu_base *base = &per_cpu(hrtimer_bases, cpu);

unsigned long flags;

if (base->hres_active)

return 1;

接着，通过tick_init_highres函数接管tick_device关联的clock_event_device：

local_irq_save(flags);

if (tick_init_highres()) {

local_irq_restore(flags);

printk(KERN_WARNING "Could not switch to high resolution "

"mode on CPU %d\n", cpu);

return 0;

}

tick_init_highres函数把tick_device切换到CLOCK_EVT_FEAT_ONESHOT模式，同时把clock_event_device的回调handler设置为hrtimer_interrupt，这样设置以后，tick_device的中断回调将由hrtimer_interrupt接管，hrtimer_interrupt在上面已经讨论过，它将完成高精度定时器的调度和到期处理。

接着，设置hres_active标志，以表明高精度模式已经切换，然后把3个时间基准系统的resolution字段设为KTIME_HIGH_RES：

base->hres_active = 1;

for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++)

base->clock_base[i].resolution = KTIME_HIGH_RES;

最后，因为tick_device被高精度定时器接管，它将不会再提供原有的tick事件机制，所以需要由高精度定时器系统模拟一个tick事件设备，继续为系统提供tick事件能力，这个工作由tick_setup_sched_timer函数完成。因为刚刚完成切换，tick_device的到期时间并没有被正确地设置为下一个到期定时器的时间，这里使用retrigger_next_event函数，传入参数NULL，使得tick_device立刻产生到期中断，hrtimer_interrupt被调用一次，然后下一个到期的定时器的时间会编程到tick_device中，从而完成了到高精度模式的切换：

tick_setup_sched_timer();

/* "Retrigger" the interrupt to get things going */

retrigger_next_event(NULL);

local_irq_restore(flags);

return 1;

}

整个切换过程可以用下图表示：

图3.1 低精度模式切换至高精度模式

4. 模拟tick事件

根据上一节的讨论，当系统切换到高精度模式后，tick_device被高精度定时器系统接管，不再定期地产生tick事件，我们知道，到目前的版本为止（V3.4），内核还没有彻底废除jiffies机制，系统还是依赖定期到来的tick事件，供进程调度系统和时间更新等操作，大量存在的低精度定时器也仍然依赖于jiffies的计数，所以，尽管tick_device被接管，高精度定时器系统还是要想办法继续提供定期的tick事件。为了达到这一目的，内核使用了一个取巧的办法：既然高精度模式已经启用，可以定义一个hrtimer，把它的到期时间设定为一个jiffy的时间，当这个hrtimer到期时，在这个hrtimer的到期回调函数中，进行和原来的tick_device同样的操作，然后把该hrtimer的到期时间顺延一个jiffy周期，如此反复循环，完美地模拟了原有tick_device的功能。下面我们看看具体点代码是如何实现的。

在kernel/time/tick-sched.c中，内核定义了一个per_cpu全局变量：tick_cpu_sched，从而为每个cpu提供了一个tick_sched结构，该结构主要用于管理NO_HZ配置下的tickless处理，因为模拟tick事件与tickless有很强的相关性，所以高精度定时器系统也利用了该结构的以下字段，用于完成模拟tick事件的操作：

struct tick_sched {

struct hrtimer sched_timer;

unsigned long check_clocks;

enum tick_nohz_mode nohz_mode;

......

};

sched_timer就是要用于模拟tick事件的hrtimer，check_clock上面几节已经讨论过，用于notify系统通知hrtimer系统需要检查是否切换到高精度模式，nohz_mode则用于表示当前的工作模式。

上一节提到，用于切换至高精度模式的函数是hrtimer_switch_to_hres，在它的最后，调用了函数tick_setup_sched_timer，该函数的作用就是设置一个用于模拟tick事件的hrtimer：

[cpp] view plain copy print ?

void tick_setup_sched_timer(void)

{

struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);

ktime_t now = ktime_get();

* Emulate tick processing via per-CPU hrtimers:

hrtimer_init(&ts->sched_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);

ts->sched_timer.function = tick_sched_timer;

/* Get the next period (per cpu) */

hrtimer_set_expires(&ts->sched_timer, tick_init_jiffy_update());

for (;;) {

hrtimer_forward(&ts->sched_timer, now, tick_period);

hrtimer_start_expires(&ts->sched_timer,

HRTIMER_MODE_ABS_PINNED);

/* Check, if the timer was already in the past */

if (hrtimer_active(&ts->sched_timer))

break;

now = ktime_get();

}

#ifdef CONFIG_NO_HZ

if (tick_nohz_enabled)

ts->nohz_mode = NOHZ_MODE_HIGHRES;

#endif

}

该函数首先初始化该cpu所属的tick_sched结构中sched_timer字段，把该hrtimer的回调函数设置为tick_sched_timer，然后把它的到期时间设定为下一个jiffy时刻，返回前把工作模式设置为NOHZ_MODE_HIGHRES，表明是利用高精度模式实现NO_HZ。

接着我们关注一下hrtimer的回调函数tick_sched_timer，我们知道，系统中的jiffies计数，时间更新等是全局操作，在smp系统中，只有一个cpu负责该工作，所以在tick_sched_timer的一开始，先判断当前cpu是否负责更新jiffies和时间，如果是，则执行更新操作：

static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)

{

......

#ifdef CONFIG_NO_HZ

if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE))

tick_do_timer_cpu = cpu;

#endif

/* Check, if the jiffies need an update */

if (tick_do_timer_cpu == cpu)

tick_do_update_jiffies64(now);

然后，利用regs指针确保当前是在中断上下文中，然后调用update_process_timer：

if (regs) {

......

update_process_times(user_mode(regs));

......

}

最后，把hrtimer的到期时间推进一个tick周期，返回HRTIMER_RESTART表明该hrtimer需要再次启动，以便产生下一个tick事件。

hrtimer_forward(timer, now, tick_period);

return HRTIMER_RESTART;

}

关于update_process_times，如果你你感兴趣，回看一下本系列关于clock_event_device的那一章：Linux时间子系统之四：定时器的引擎：clock_event_device中的第5小节，对比一下模拟tick事件的hrtimer的回调函数tick_sched_timer和切换前tick_device的回调函数tick_handle_periodic，它们是如此地相像，实际上，它们几乎完成了一样的工作。

7. Linux时间子系统之七：定时器的应用--msleep()，hrtimer_nanosleep()

我们已经在前面几章介绍了低分辨率定时器和高精度定时器的实现原理，内核为了方便其它子系统，在时间子系统中提供了一些用于延时或调度的API，例如msleep，hrtimer_nanosleep等等，这些API基于低分辨率定时器或高精度定时器来实现，本章的内容就是讨论这些方便、好用的API是如何利用定时器系统来完成所需的功能的。

1. msleep

msleep相信大家都用过，它可能是内核用使用最广泛的延时函数之一，它会使当前进程被调度并让出cpu一段时间，因为这一特性，它不能用于中断上下文，只能用于进程上下文中。要想在中断上下文中使用延时函数，请使用会阻塞cpu的无调度版本mdelay。msleep的函数原型如下：

void msleep(unsigned int msecs)

延时的时间由参数msecs指定，单位是毫秒，事实上，msleep的实现基于低分辨率定时器，所以msleep的实际精度只能也是1/HZ级别。内核还提供了另一个比较类似的延时函数msleep_interruptible：

unsigned long msleep_interruptible(unsigned int msecs)

延时的单位同样毫秒数，它们的区别如下：

函数	延时单位	返回值	是否可被信号中断
msleep	毫秒	无	否
msleep_interruptible	毫秒	未完成的毫秒数	是

最主要的区别就是msleep会保证所需的延时一定会被执行完，而msleep_interruptible则可以在延时进行到一半时被信号打断而退出延时，剩余的延时数则通过返回值返回。两个函数最终的代码都会到达schedule_timeout函数，它们的调用序列如下图所示：

图1.1 两个延时函数的调用序列

下面我们看看schedule_timeout函数的实现，函数首先处理两种特殊情况，一种是传入的延时jiffies数是个负数，则打印一句警告信息，然后马上返回，另一种是延时jiffies数是MAX_SCHEDULE_TIMEOUT，表明需要一直延时，直接执行调度即可：

signed long __sched schedule_timeout(signed long timeout)

{

struct timer_list timer;

unsigned long expire;

switch (timeout)

{

case MAX_SCHEDULE_TIMEOUT:

schedule();

goto out;

default:

if (timeout < 0) {

printk(KERN_ERR "schedule_timeout: wrong timeout "

"value %lx\n", timeout);

dump_stack();

current->state = TASK_RUNNING;

goto out;

}

然后计算到期的jiffies数，并在堆栈上建立一个低分辨率定时器，把到期时间设置到该定时器中，启动定时器后，通过schedule把当前进程调度出cpu的运行队列：

expire = timeout + jiffies;

setup_timer_on_stack(&timer, process_timeout, (unsigned long)current);

__mod_timer(&timer, expire, false, TIMER_NOT_PINNED);

schedule();

到这个时候，进程已经被调度走，那它如何返回继续执行？我们看到定时器的到期回调函数是process_timeout，参数是当前进程的task_struct指针，看看它的实现：

static void process_timeout(unsigned long __data)

{

wake_up_process((struct task_struct *)__data);

}

噢，没错，定时器一旦到期，进程会被唤醒并继续执行：

del_singleshot_timer_sync(&timer);

/* Remove the timer from the object tracker */

destroy_timer_on_stack(&timer);

timeout = expire - jiffies;

out:

return timeout < 0 ? 0 : timeout;

}

schedule返回后，说明要不就是定时器到期，要不就是因为其它时间导致进程被唤醒，函数要做的就是删除在堆栈上建立的定时器，返回剩余未完成的jiffies数。

说完了关键的schedule_timeout函数，我们看看msleep如何实现：

signed long __sched schedule_timeout_uninterruptible(signed long timeout)

{

__set_current_state(TASK_UNINTERRUPTIBLE);

return schedule_timeout(timeout);

}

void msleep(unsigned int msecs)

{

unsigned long timeout = msecs_to_jiffies(msecs) + 1;

while (timeout)

timeout = schedule_timeout_uninterruptible(timeout);

}

msleep先是把毫秒转换为jiffies数，通过一个while循环保证所有的延时被执行完毕，延时操作通过schedule_timeout_uninterruptible函数完成，它仅仅是在把进程的状态修改为TASK_UNINTERRUPTIBLE后，调用上述的schedule_timeout来完成具体的延时操作，TASK_UNINTERRUPTIBLE状态保证了msleep不会被信号唤醒，也就意味着在msleep期间，进程不能被kill掉。

看看msleep_interruptible的实现：

signed long __sched schedule_timeout_interruptible(signed long timeout)

{

__set_current_state(TASK_INTERRUPTIBLE);

return schedule_timeout(timeout);

}

unsigned long msleep_interruptible(unsigned int msecs)

{

unsigned long timeout = msecs_to_jiffies(msecs) + 1;

while (timeout && !signal_pending(current))

timeout = schedule_timeout_interruptible(timeout);

return jiffies_to_msecs(timeout);

}

msleep_interruptible通过schedule_timeout_interruptible中转，schedule_timeout_interruptible的唯一区别就是把进程的状态设置为了TASK_INTERRUPTIBLE，说明在延时期间有信号通知，while循环会马上终止，剩余的jiffies数被转换成毫秒返回。实际上，你也可以利用schedule_timeout_interruptible或schedule_timeout_uninterruptible构造自己的延时函数，同时，内核还提供了另外一个类似的函数，不用我解释，看代码就知道它的用意了：

signed long __sched schedule_timeout_killable(signed long timeout)

{

__set_current_state(TASK_KILLABLE);

return schedule_timeout(timeout);

}

2. hrtimer_nanosleep

第一节讨论的msleep函数基于时间轮定时系统，只能提供毫秒级的精度，实际上，它的精度取决于HZ的配置值，如果HZ小于1000，它甚至无法达到毫秒级的精度，要想得到更为精确的延时，我们自然想到的是要利用高精度定时器来实现。没错，linux为用户空间提供了一个api：nanosleep，它能提供纳秒级的延时精度，该用户空间函数对应的内核实现是sys_nanosleep，它的工作交由高精度定时器系统的hrtimer_nanosleep函数实现，最终的大部分工作则由do_nanosleep完成。调用过程如下图所示：

图 2.1 nanosleep的调用过程

与msleep的实现相类似，hrtimer_nanosleep函数首先在堆栈中创建一个高精度定时器，设置它的到期时间，然后通过do_nanosleep完成最终的延时工作，当前进程在挂起相应的延时时间后，退出do_nanosleep函数，销毁堆栈中的定时器并返回0值表示执行成功。不过do_nanosleep可能在没有达到所需延时数量时由于其它原因退出，如果出现这种情况，hrtimer_nanosleep的最后部分把剩余的延时时间记入进程的restart_block中，并返回ERESTART_RESTARTBLOCK错误代码，系统或者用户空间可以根据此返回值决定是否重新调用nanosleep以便把剩余的延时继续执行完成。下面是hrtimer_nanosleep的代码：

long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,

const enum hrtimer_mode mode, const clockid_t clockid)

{

struct restart_block *restart;

struct hrtimer_sleeper t;

int ret = 0;

unsigned long slack;

slack = current->timer_slack_ns;

if (rt_task(current))

slack = 0;

hrtimer_init_on_stack(&t.timer, clockid, mode);

hrtimer_set_expires_range_ns(&t.timer, timespec_to_ktime(*rqtp), slack);

if (do_nanosleep(&t, mode))

goto out;

/* Absolute timers do not update the rmtp value and restart: */

if (mode == HRTIMER_MODE_ABS) {

ret = -ERESTARTNOHAND;

goto out;

}

if (rmtp) {

ret = update_rmtp(&t.timer, rmtp);

if (ret <= 0)

goto out;

}

restart = ¤t_thread_info()->restart_block;

restart->fn = hrtimer_nanosleep_restart;

restart->nanosleep.clockid = t.timer.base->clockid;

restart->nanosleep.rmtp = rmtp;

restart->nanosleep.expires = hrtimer_get_expires_tv64(&t.timer);

ret = -ERESTART_RESTARTBLOCK;

out:

destroy_hrtimer_on_stack(&t.timer);

return ret;

}

接着我们看看do_nanosleep的实现代码，它首先通过hrtimer_init_sleeper函数，把定时器的回调函数设置为hrtimer_wakeup，把当前进程的task_struct结构指针保存在hrtimer_sleeper结构的task字段中：

void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, struct task_struct *task)

{

sl->timer.function = hrtimer_wakeup;

sl->task = task;

}

EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);

static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mode)

{

hrtimer_init_sleeper(t, current);

然后，通过一个do/while循环内：启动定时器，挂起当前进程，等待定时器或其它事件唤醒进程。这里的循环体实现比较怪异，它使用hrtimer_active函数间接地判断定时器是否到期，如果hrtimer_active返回false，说明定时器已经过期，然后把hrtimer_sleeper结构的task字段设置为NULL，从而导致循环体的结束，另一个结束条件是当前进程收到了信号事件，所以，当因为是定时器到期而退出时，do_nanosleep返回true，否则返回false，上述的hrtimer_nanosleep正是利用了这一特性来决定它的返回值。以下是do_nanosleep循环体的代码：

do {

set_current_state(TASK_INTERRUPTIBLE);

hrtimer_start_expires(&t->timer, mode);

if (!hrtimer_active(&t->timer))

t->task = NULL;

if (likely(t->task))

schedule();

hrtimer_cancel(&t->timer);

mode = HRTIMER_MODE_ABS;

} while (t->task && !signal_pending(current));

__set_current_state(TASK_RUNNING);

return t->task == NULL;

}

除了hrtimer_nanosleep，高精度定时器系统还提供了几种用于延时/挂起进程的api：

schedule_hrtimeout 使得当前进程休眠指定的时间，使用CLOCK_MONOTONIC计时系统；

schedule_hrtimeout_range 使得当前进程休眠指定的时间范围，使用CLOCK_MONOTONIC计时系统；

schedule_hrtimeout_range_clock 使得当前进程休眠指定的时间范围，可以自行指定计时系统；

usleep_range 使得当前进程休眠指定的微妙数，使用CLOCK_MONOTONIC计时系统；

它们之间的调用关系如下：

图 2.2 schedule_hrtimeout_xxxx系列函数

最终，所有的实现都会进入到schedule_hrtimeout_range_clock函数。需要注意的是schedule_hrtimeout_xxxx系列函数在调用前，最好利用set_current_state函数先设置进程的状态，在这些函数返回前，进城的状态会再次被设置为TASK_RUNNING。如果事先把状态设置为TASK_UNINTERRUPTIBLE，它们会保证函数返回前一定已经经过了所需的延时时间，如果事先把状态设置为TASK_INTERRUPTIBLE，则有可能在尚未到期时由其它信号唤醒进程从而导致函数返回。主要实现该功能的函数schedule_hrtimeout_range_clock和前面的do_nanosleep函数实现原理基本一致。大家可以自行参考内核的代码，它们位于：kernel/hrtimer.c。

8. Linux时间子系统之八：动态时钟框架（CONFIG_NO_HZ、tickless）

在前面章节的讨论中，我们一直基于一个假设：Linux中的时钟事件都是由一个周期时钟提供，不管系统中的clock_event_device是工作于周期触发模式，还是工作于单触发模式，也不管定时器系统是工作于低分辨率模式，还是高精度模式，内核都竭尽所能，用不同的方式提供周期时钟，以产生定期的tick事件，tick事件或者用于全局的时间管理（jiffies和时间的更新），或者用于本地cpu的进程统计、时间轮定时器框架等等。周期性时钟虽然简单有效，但是也带来了一些缺点，尤其在系统的功耗上，因为就算系统目前无事可做，也必须定期地发出时钟事件，激活系统。为此，内核的开发者提出了动态时钟这一概念，我们可以通过内核的配置项CONFIG_NO_HZ来激活特性。有时候这一特性也被叫做tickless，不过还是把它称呼为动态时钟比较合适，因为并不是真的没有tick事件了，只是在系统无事所做的idle阶段，我们可以通过停止周期时钟来达到降低系统功耗的目的，只要有进程处于活动状

在动态时钟正确工作之前，系统需要切换至动态时钟模式，而要切换至动态时钟模式，需要一些前提条件，最主要的一条就是cpu的时钟事件设备必须要支持单触发模式，当条件满足时，系统切换至动态时钟模式，接着，由idle进程决定是否可以停止周期时钟，退出idle进程时则需要恢复周期时钟。

1. 数据结构

在上一章的内容里，我们曾经提到，切换到高精度模式后，高精度定时器系统需要使用一个高精度定时器来模拟传统的周期时钟，其中利用了tick_sched结构中的一些字段，事实上，tick_sched结构也是实现动态时钟的一个重要的数据结构，在smp系统中，内核会为每个cpu都定义一个tick_sched结构，这通过一个percpu全局变量tick_cpu_sched来实现，它在kernel/time/tick-sched.c中定义：

* Per cpu nohz control structure

static DEFINE_PER_CPU(struct tick_sched, tick_cpu_sched);

tick_sched结构在include/linux/tick.h中定义，我们看看tick_sched结构的详细定义：

struct tick_sched {

struct hrtimer sched_timer;

unsigned long check_clocks;

enum tick_nohz_mode nohz_mode;

ktime_t idle_tick;

int inidle;

int tick_stopped;

unsigned long idle_jiffies;

unsigned long idle_calls;

unsigned long idle_sleeps;

int idle_active;

ktime_t idle_entrytime;

ktime_t idle_waketime;

ktime_t idle_exittime;

ktime_t idle_sleeptime;

ktime_t iowait_sleeptime;

ktime_t sleep_length;

unsigned long last_jiffies;

unsigned long next_jiffies;

ktime_t idle_expires;

int do_timer_last;

};

sched_timer 该字段用于在高精度模式下，模拟周期时钟的一个hrtimer，请参看Linux时间子系统之六：高精度定时器（HRTIMER）的原理和实现。

check_clocks 该字段用于实现clock_event_device和clocksource的异步通知机制，帮助系统切换至高精度模式或者是动态时钟模式。

nohz_mode 保存动态时钟的工作模式，基于低分辨率和高精度模式下，动态时钟的实现稍有不同，根据模式它可以是以下的值：

NOHZ_MODE_INACTIVE 系统动态时钟尚未激活

NOHZ_MODE_LOWRES 系统工作于低分辨率模式下的动态时钟

NOHZ_MODE_HIGHRES 系统工作于高精度模式下的动态时钟

idle_tick 该字段用于保存停止周期时钟是的内核时间，当退出idle时要恢复周期时钟，需要使用该时间，以保持系统中时间线（jiffies）的正确性。

tick_stopped 该字段用于表明idle状态的周期时钟已经停止。

idle_jiffies 系统进入idle时的jiffies值，用于信息统计。

idle_calls 系统进入idle的统计次数。

idle_sleeps 系统进入idle且成功停掉周期时钟的次数。

idle_active 表明目前系统是否处于idle状态中。

idle_entrytime 系统进入idle的时刻。

idle_waketime idle状态被打断的时刻。

idle_exittime 系统退出idle的时刻。

idle_sleeptime 累计各次idle中停止周期时钟的总时间。

sleep_length 本次idle中停止周期时钟的时间。

last_jiffies 系统中最后一次周期时钟的jiffies值。

next_jiffies 预计下一次周期时钟的jiffies。

idle_expires 进入idle后，下一个最先到期的定时器时刻。

我们知道，根据系统目前的工作模式，系统提供周期时钟（tick）的方式会有所不同，当处于低分辨率模式时，由cpu的tick_device提供周期时钟，而当处于高精度模式时，是由一个高精度定时器来提供周期时钟，下面我们分别讨论一下在两种模式下的动态时钟实现方式。

2. 低分辨率下的动态时钟

回看之前一篇文章：Linux时间子系统之四：定时器的引擎：clock_event_device中的关于tick_device一节，不管tick_device的工作模式（周期触发或者是单次触发），tick_device所关联的clock_event_device的事件回调处理函数都是：tick_handle_periodic，不管当前是否处于idle状态，他都会精确地按HZ数来提供周期性的tick事件，这不符合动态时钟的要求，所以，要使动态时钟发挥作用，系统首先要切换至支持动态时钟的工作模式：NOHZ_MODE_LOWRES 。

2.1 切换至动态时钟模式

动态时钟模式的切换过程的前半部分和切换至高精度定时器模式所经过的路径是一样的，请参考：Linux时间子系统之六：高精度定时器（HRTIMER）的原理和实现。这里再简单描述一下过程：系统工作于周期时钟模式，定期地发出tick事件中断，tick事件中断触发定时器软中断：TIMER_SOFTIRQ，执行软中断处理函数run_timer_softirq，run_timer_softirq调用hrtimer_run_pending函数：

void hrtimer_run_pending(void)

{

if (hrtimer_hres_active())

return;

......

if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))

hrtimer_switch_to_hres();

}

tick_check_oneshot_change函数的参数决定了现在是要切换至低分辨率动态时钟模式，还是高精度定时器模式，我们现在假设系统不支持高精度定时器模式，hrtimer_is_hres_enabled会直接返回false，对应的tick_check_oneshot_change函数的参数则是true，表明需要切换至动态时钟模式。tick_check_oneshot_change在检查过timekeeper和clock_event_device都具备动态时钟的条件后，通过tick_nohz_switch_to_nohz函数切换至动态时钟模式：

首先，该函数通过tick_switch_to_oneshot函数把tick_device的工作模式设置为单触发模式，并把它的中断事件回调函数置换为tick_nohz_handler，接着把tick_sched结构中的模式字段设置为NOHZ_MODE_LOWRES：

static void tick_nohz_switch_to_nohz(void)

{

struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);

ktime_t next;

if (!tick_nohz_enabled)

return;

local_irq_disable();

if (tick_switch_to_oneshot(tick_nohz_handler)) {

local_irq_enable();

return;

}

ts->nohz_mode = NOHZ_MODE_LOWRES;

然后，初始化tick_sched结构中的sched_timer定时器，通过tick_init_jiffy_update获取下一次tick事件的时间并初始化全局变量last_jiffies_update，以便后续可以正确地更新jiffies计数值，最后，把下一次tick事件的时间编程到tick_device中，到此，系统完成了到低分辨率动态时钟的切换过程。

hrtimer_init(&ts->sched_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);

/* Get the next period */

next = tick_init_jiffy_update();

for (;;) {

hrtimer_set_expires(&ts->sched_timer, next);

if (!tick_program_event(next, 0))

break;

next = ktime_add(next, tick_period);

}

local_irq_enable();

}

上面的代码中，明明现在没有切换至高精度模式，为什么要初始化tick_sched结构中的高精度定时器？原因并不是要使用它的定时功能，而是想重用hrtimer代码中的hrtimer_forward函数，利用这个函数来计算下一次tick事件的时间。

2.2 低分辨率动态时钟下的事件中断处理函数

上一节提到，当切换至低分辨率动态时钟模式后，tick_device的事件中断处理函数会被设置为tick_nohz_handler，总体来说，它和周期时钟模式的事件处理函数tick_handle_periodic所完成的工作大致类似：更新时间、更新jiffies计数值、调用update_process_time更新进程信息和触发定时器软中断等等，最后重新编程tick_device，使得它在下一个正确的tick时刻再次触发本函数：

static void tick_nohz_handler(struct clock_event_device *dev)

{

......

dev->next_event.tv64 = KTIME_MAX;

if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE))

tick_do_timer_cpu = cpu;

/* Check, if the jiffies need an update */

if (tick_do_timer_cpu == cpu)

tick_do_update_jiffies64(now);

......

if (ts->tick_stopped) {

touch_softlockup_watchdog();

ts->idle_jiffies++;

}

update_process_times(user_mode(regs));

profile_tick(CPU_PROFILING);

while (tick_nohz_reprogram(ts, now)) {

now = ktime_get();

tick_do_update_jiffies64(now);

}

因为现在工作于动态时钟模式，所以，tick时钟可能在idle进程中被停掉不止一个tick周期，所以当该函数被再次触发时，离上一次触发的时间可能已经不止一个tick周期，tick_nohz_reprogram对tick_device进行编程时必须正确地处理这一情况，它利用了前面所说的hrtimer_forward函数来实现这一特性：

static int tick_nohz_reprogram(struct tick_sched *ts, ktime_t now)

{

hrtimer_forward(&ts->sched_timer, now, tick_period);

return tick_program_event(hrtimer_get_expires(&ts->sched_timer), 0);

}

2.3 动态时钟：停止周期tick时钟事件

开启动态时钟模式后，周期时钟的开启和关闭由idle进程控制，idle进程内最终是一个循环，循环的一开始通过tick_nohz_idle_enter检测是否允许关闭周期时钟若干时间，然后进入低功耗的idle模式，当有中断事件使得cpu退出低功耗idle模式后，判断是否有新的进程被激活从而需要重新调度，如果需要则通过tick_nohz_idle_exit重新启用周期时钟，然后重新进行进程调度，等待下一次idle的发生，我们可以用下图来表示：

图2.3.1 idle进程中的动态时钟处理

停止周期时钟的时机在tick_nohz_idle_enter函数中，它把主要的工作交由tick_nohz_stop_sched_tick函数来完成。内核也不是每次进入tick_nohz_stop_sched_tick都会停止周期时钟，那么什么时候才会停止？我们想一想，这时候既然idle进程在运行，说明系统中的其他进程都在等待某种事件，系统处于无事所做的状态，唯一要处理的就是中断，除了定时器中断，其它的中断我们无法预测它会何时发生，但是我们可以知道最先一个到期的定时器的到期时间，也就是说，在该时间到期前，产生周期时钟是没有必要的，我们可以据此推算出周期时钟可以停止的tick数，然后重新对tick_device进行编程，使得在最早一个定时器到期前都不会产生周期时钟，实际上，tick_nohz_stop_sched_tick还做了一些限制：当下一个定时器的到期时间与当前jiffies值只相差1时，不会停止周期时钟，当定时器的到期时间与当前的jiffies值相差的时间大于timekeeper允许的最大idle时间时，则下一个tick时刻被设置timekeeper允许的最大idle时间，这主要是为了防止太长时间不去更新timekeeper中的系统时间，有可能导致clocksource的溢出问题。tick_nohz_stop_sched_tick函数体看起来很长，实现的也就是上述的逻辑，所以这里就不贴它的代码了，有兴趣的读者可以自行阅读内核的代码：kernel/time/tick-sched.c。

看了动态时钟的停止过程和tick_nohz_handler的实现方式，其实还有一个情况没有处理：当系统进入idle进程后，周期时钟被停止若干个tick周期，当这若干个tick周期到期后，tick事件必然会产生，tick_nohz_handler被触发调用，然后最先到期的定时器被处理。但是在tick_nohz_handler的最后，tick_device一定会被编程为紧跟着的下一个tick周期的时刻被触发，如果刚才的定时器处理后，并没有激活新的进程，我们的期望是周期时钟可以用下一个新的定时器重新计算可以停止的时间，而不是下一个tick时刻，但是tick_nohz_handler却仅仅简单地把tick_device的到期时间设为下一个周期的tick时刻，这导致了周期时钟被恢复，显然这不是我们想要的。为了处理这种情况，内核使用了一点小伎俩，我们知道定时器是在软中断中执行的，所以内核在irq_exit中的软件中断处理完后，加入了一小段代码，kernel/softirq.c ：

void irq_exit(void)

{

......

if (!in_interrupt() && local_softirq_pending())

invoke_softirq();

#ifdef CONFIG_NO_HZ

/* Make sure that timer wheel updates are propagated */

if (idle_cpu(smp_processor_id()) && !in_interrupt() && !need_resched())

tick_nohz_irq_exit();

#endif

......

}

关键的调用是tick_nohz_irq_exit：

void tick_nohz_irq_exit(void)

{

struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);

if (!ts->inidle)

return;

tick_nohz_stop_sched_tick(ts);

}

tick_nohz_irq_exit再次调用了tick_nohz_stop_sched_tick函数，使得系统有机会再次停止周期时钟若干个tick周期。

2.3 动态时钟：重新开启周期tick时钟事件

回到图2.3.1，当在idle进程中停止周期时钟后，在某一时刻，有新的进程被激活，在重新调度前，tick_nohz_idle_exit会被调用，该函数负责恢复被停止的周期时钟。tick_nohz_idle_exit最终会调用tick_nohz_restart函数，由tick_nohz_restart函数最后完成恢复周期时钟的工作。函数并不复杂：先是把上一次停止周期时钟的时刻设置到tick_sched结构的sched_timer定时器中，然后在通过hrtimer_forward函数把该定时器的到期时刻设置为当前时间的下一个tick时刻，对于高精度模式，启动该定时器即可，对于低分辨率模式，使用该时间对tick_device重新编程，最后通过tick_do_update_jiffies64更新jiffies数值，为了防止此时正在一个tick时刻的边界，可能当前时刻正好刚刚越过了该到期时间，函数使用了一个while循环：

static void tick_nohz_restart(struct tick_sched *ts, ktime_t now)

{

hrtimer_cancel(&ts->sched_timer);

hrtimer_set_expires(&ts->sched_timer, ts->idle_tick);

while (1) {

/* Forward the time to expire in the future */

hrtimer_forward(&ts->sched_timer, now, tick_period);

if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {

hrtimer_start_expires(&ts->sched_timer,

HRTIMER_MODE_ABS_PINNED);

/* Check, if the timer was already in the past */

if (hrtimer_active(&ts->sched_timer))

break;

} else {

if (!tick_program_event(

hrtimer_get_expires(&ts->sched_timer), 0))

break;

}

/* Reread time and update jiffies */

now = ktime_get();

tick_do_update_jiffies64(now);

}

3. 高精度模式下的动态时钟

高精度模式和低分辨率模式的主要区别是在切换过程中，怎样切换到高精度模式，我已经在上一篇文章中做了说明，切换到高精度模式后，动态时钟的开启和关闭和低分辨率模式下没有太大的区别，也是通过tick_nohz_stop_sched_tick和tick_nohz_restart来控制，在这两个函数中，分别判断了当前的两种模式：

NOHZ_MODE_HIGHRES

NOHZ_MODE_LOWRES

如果是NOHZ_MODE_HIGHRES则对tick_sched结构的sched_timer定时器进行设置，如果是NOHZ_MODE_LOWRES，则直接对tick_device进行操作。

4. 动态时钟对中断的影响

在进入和退出中断时，因为动态时钟的关系，中断系统需要作出一些配合。先说中断发生于周期时钟停止期间，如果不做任何处理，中断服务程序中如果要访问jiffies计数值，可能得到一个滞后的jiffies值，因为正常状态下，jiffies值会在恢复周期时钟时正确地更新，所以，为了防止这种情况发生，在进入中断的irq_enter期间，tick_check_idle会被调用：

void tick_check_idle(int cpu)

{

tick_check_oneshot_broadcast(cpu);

tick_check_nohz(cpu);

}

tick_check_nohz函数的最重要的作用就是更新jiffies计数值：

static inline void tick_check_nohz(int cpu)

{

struct tick_sched *ts = &per_cpu(tick_cpu_sched, cpu);

ktime_t now;

if (!ts->idle_active && !ts->tick_stopped)

return;

now = ktime_get();

if (ts->idle_active)

tick_nohz_stop_idle(cpu, now);

if (ts->tick_stopped) {

tick_nohz_update_jiffies(now);

tick_nohz_kick_tick(cpu, now);

}

另外一种情况是在退出定时器中断时，需要重新评估周期时钟的运行状况，这一点已经在2.3节中做了说明，这里就不在赘述了。

GitHub 加速计划 / li / linux-dash

10.39 K

1.2 K

下载

A beautiful web dashboard for Linux

最近提交(Master分支：2 个月前 )

186a802e added ecosystem file for PM2 4 年前

5def40a3 Add host customization support for the NodeJS version 4 年前

GitCode 开源社区

旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。

更多推荐

[转载]在Windows环境下安装GNU Radio

转自：在Windows环境下安装GNURadio_恐弱智_新浪博客GNU Radio是用Python开发的，大部分开源的工程能够在Linux环境下运行良好，而Windows下却运行的很勉强，而且安装配置都很复杂。GNU Radio算是个例外了，不光提供了Windows的二进制安装，还有比较详细的说明。我是Python小白，所以折腾了好久才弄好，特意记录下来，免得以后再装还折腾。GNU Radio的

GitCode 开源社区

centOS 8 使用dnf安装Docker

DNF是什么？CentOS 8使用YUM软件包管理器版本v4.0.4。现在，该版本使用DNF(已删除YUM)。DNF是软件包管理器。它会在Linux发行版上安装，执行更新并删除软件包。使用DNF安装Docker跳过具有损坏依赖性的程序包一个有效的解决方案是使您的CentOS 8系统使用以下--nobest命令安装最符合条件的版本：sudo dnf install docker...

GitCode 开源社区

定时同步数据库表(mysql+linux+crontab)

sync.sh里面的参数需要改变，ip/username/password/database/tablesync.sh#!/bin/sh# Please change the IP and password of the data source db.# Then change the table name.filename=/home/nington/db/$(date +%Y-%m