前言
在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。
总结
到此这篇关于Linux时间子系统之时间的表示的文章就介绍到这了,更多相关Linux时间的表示内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
