前言
在Linux内核中，为了兼容原有的代码，或者符合某种规范，并且还要满足当前精度日益提高的要求，实现了多种与时间相关但用于不同目的的数据结构：
1）jiffies和jiffies_64
内核用jiffies_64全局变量记录系统自启动以来经过了多少次Tick。它的声明如下（代码位于kernel/time/timer.c中）：
__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES; EXPORT_SYMBOL(jiffies_64);
可以看出来jiffies_64被定义成了64位无符号整数。但是，由于历史的原因，内核源代码中还包含了另一个叫做jiffies的变量。jiffies的引用（代码位于include/linux/jiffies.h中）申明为：
extern u64 __cacheline_aligned_in_smp jiffies_64; extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
因此，jiffies变量是一个unsigned long类型的全局变量，如果在32位处理器上只有4个字节长（32位）。但是，如果在64位处理器上也有8个字节长（64位），这时候jiffies和jiffies_64两个全局变量是完全等价的。
但是翻遍所有代码你也找不到全局变量jiffies的定义，最终在内核的链接脚本中（对于Arm64架构来说脚本位于arch/arm64/kernel/vmlinux.lds.S中）找到了下面这行：
jiffies = jiffies_64;
玄机在这里，原来在链接的时候指定了符号jiffies和jiffies_64指向同一个地址。也就是说，在32位机器上，jiffies和jiffies_64的低4个字节是一样的。
一般情况下，无论在32位或64位机器上，我们都可以直接访问jiffies全局变量，但如果要获得jiffies_64全局变量，则需要调用get_jiffies_64函数。对于64位系统来说，两者一样，而且jiffies被申明成了volatile的且是Cache对齐的，因此只需要直接返回jiffies就好了：
static inline u64 get_jiffies_64(void)
{
return (u64)jiffies;
}
而对于32位系统来说，由于其对64位读写不是原子的，所以还需要持有jiffies_lock读顺序锁：
u64 get_jiffies_64(void)
{
unsigned int seq;
u64 ret;
do {
seq = read_seqbegin(&jiffies_lock);
ret = jiffies_64;
} while (read_seqretry(&jiffies_lock, seq));
return ret;
}
jiffies基本上是每一次Tick到来都会加1的，而Tick的周期HZ是由内核编译选项配置的。在32位系统中，我们假设HZ被设置成了250，那么每个Tick的周期就是4毫秒，那么该计数器将在不到200天后达到最大值后溢出。如果HZ被设置的更高，那这个溢出时间会更短。当然，如果在64位系统中，则完全不用考虑这个问题。因此，在用jiffies进行时间比较的时候，需要用系统已经定义好的几个宏：
time_after(a,b) time_before(a,b) time_after_eq(a,b) time_before_eq(a,b) time_in_range_open(a,b,c) time_is_before_jiffies(a) time_is_after_jiffies(a) time_is_before_eq_jiffies(a) time_is_after_eq_jiffies(a)
为了保险起见，内核也提供了对应的64位版本。这些宏可以有效的解决回绕问题，不过也不是无限制的。具体是怎么做到的呢？我们挑一个time_after宏来看看就知道了：
#define time_after(a,b) (typecheck(unsigned long, a) && typecheck(unsigned long, b) && ((long)((b) - (a)) < 0))
先是对两个变量做类型检查，必须都是unsigned long型的。最重要的是后面，先将两个无符号长整形相减，然后将他们变成有符号的长整型，再判断其是否为负数，也就是32位的最高位是否为1。
为什么这样可以部分解决所谓回绕的问题呢？我们可以举个例子，为了简单起见，以8位无符号整数为例，其取值范围是0到255（0xFF）。假设当前时间是250，那么过5个Tick之后，就是255了，已经到达了能表达的最大值。这时，如果再过一个Tick，也就是6个Tick之后，就将会溢出变成0了。此时，如果简单的通过对两个值的比较来判断哪个时间再后面的话，显然就要出错了，因为过了6个Tick之后的时间是0，反而小于当前的时间，这个问题就是所谓的回绕。但是，如果我们先将这两个数相减，也就是0-250（0-0xFA）,也会产生溢出，最终得到的数刚好是6。但这也是有限制的，两个比较的时间之间的差值不能超过最大表示范围的一半。假设现在的时间还是250，而过了128个Tick之后，时间值将变成122，再将两者相减的话就是122-250（0x86-0xFA），减出来的数字就是128了，此时转成有符号数就变成负数了，结果就错了。
另外，jiffies是每个Tick更新一次的，而Tick的周期又是编译的时候定义好的，所以可以将jiffies的数值转换成具体过了多少时间，反之亦然。因此，内核提供了如下转换函数：
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）timespec和timespec64
timespec由秒和纳秒组成，其定义如下（代码位于include/uapi/linux/time.h）：
struct timespec {
__kernel_time_t tv_sec;
long tv_nsec;
};
tv_sec：存放自1970年1月1日0时（UTC时间）以来经过的秒数。__kernel_time_t最终定义成了long型，也就是在32位系统上是32位长，而在64位系统上是64位长。
tv_nsec：存放自上一秒开始经过的纳秒（ns）数。
timespec还有一个64位的扩展结构，其定义如下（代码位于include/linux/time64.h）：
typedef __s64 time64_t;
......
struct timespec64 {
time64_t tv_sec;
long tv_nsec;
};
这个结构体中的变量定义和timespec一样，只不过tv_sec的类型一定是64位无符号数。所以，也就是说在64位系统上，timespec和timespec64结构体是一模一样的。
3）ktime_t
在Linux的时间子系统内，一般使用ktime_t来表示时间，其定义如下（代码位于include/linux/ktime.h）：
typedef s64 ktime_t;
就是一个非常简单的64位带符号整数，表示的时间单位是纳秒。
4）timeval
gettimeofday和settimeofday函数使用timeval作为时间单位：
struct timeval {
__kernel_time_t tv_sec;
__kernel_suseconds_t tv_usec;
};
tv_sec：存放自1970年1月1日0时（UTC时间）以来经过的秒数。__kernel_time_t最终定义成了long型，也就是在32位系统上是32位长，而在64位系统上是64位长。
tv_usec：__kernel_suseconds_t实际最终也被定义成了long型，存放自上一秒开始经过的微秒（us）数。
所以，这个结构体其实和timespec结构体大同小异，tv_sec存的值是一样的，而只需要将timespec中的tv_nsec除以1000就是timeval中的tv_usec。
