Linux时间子系统之时间的表示

在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。

收藏 (0)
评论列表
正在载入评论列表...
我是有底线的