热门标签 | HotTags
当前位置:  开发笔记 > 运维 > 正文

Linux时间子系统之时间的表示示例详解

这篇文章主要给大家介绍了关于Linux时间子系统之时间的表示的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用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。

总结

到此这篇关于Linux时间子系统之时间的表示的文章就介绍到这了,更多相关Linux时间的表示内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!


推荐阅读
  • 重新审视Kubernetes的必要性
    近期,我注意到不少人误以为我是Kubernetes的推广者。实际上,我只是分享了一些适合用Kubernetes解决的案例。本文旨在探讨Kubernetes的适用场景,并提供一些替代方案。 ... [详细]
  • UMPlatForm.NET 5.1 版本数据字典管理功能解析
    本文介绍了 UMPlatForm.NET 5.1 版本中的数据字典管理模块,探讨了该模块如何支持平台的数据共享与管理,以及如何通过用户和角色权限来增强系统的安全性。 ... [详细]
  • 本文探讨了Python的csv模块在不同操作系统上生成文件时,默认使用DOS风格的行尾字符(即'')的问题,并提供了如何修改这一行为的方法。 ... [详细]
  • 本文介绍了如何将Linux系统中的YUM源更换为阿里云镜像源,包括网络连通性测试、原YUM源的移除、阿里云YUM源的配置以及缓存的更新等步骤。 ... [详细]
  • FTP作为一种传统的文件传输协议,广泛用于不同设备间的文件交换。然而,随着网络安全需求的提升及传输效率的要求,选择合适的FTP客户端变得尤为重要。本文将介绍如何利用WinSCP这款强大且安全的工具,实现两台电脑之间的文件高效传输。 ... [详细]
  • 本文探讨了 Boost 库中的 Program Options 组件,这是一个强大的工具,用于解析命令行参数和配置文件。文章介绍了如何正确设置和使用该组件,包括处理复杂选项和负数值的方法。 ... [详细]
  • 对于初次购买阿里云服务器的新手用户来说,如何高效地利用服务器资源并成功部署网站是一个重要的课题。本文将详细指导您完成从购买服务器到网站上线的六个关键步骤。 ... [详细]
  • GCC(GNU Compiler Collection)是GNU项目下的一款功能全面且高效的多平台编译工具,广泛应用于Linux操作系统中。本文将详细介绍GCC的特点及其基本使用方法。 ... [详细]
  • 本文探讨了如何使Shell和程序同时响应Ctrl-C信号的方法,即通过将两者置于同一进程组并将其设为终端的前台进程组。 ... [详细]
  • 如何更换Anaconda和pip的国内镜像源
    本文详细介绍了如何通过国内多个知名镜像站(如北京外国语大学、中国科学技术大学、阿里巴巴等)更换Anaconda和pip的源,以提高软件包的下载速度和安装效率。 ... [详细]
  • 探讨Linux系统中PCI设备的I/O地址与内存映射的区别及其实现方式。 ... [详细]
  • 在尝试使用Ubuntu 10.04进行Android开发时,遇到了系统无法识别HTC G1设备的情况。本文将详细介绍如何通过配置系统和安装必要的驱动来解决这一问题。 ... [详细]
  • 本文详细介绍了如何使用 Python 编程语言中的 Scapy 库执行 DNS 欺骗攻击,包括必要的软件安装、攻击流程及代码示例。 ... [详细]
  • 本文介绍了Linux内核中TCP的三种接收队列:Prequeue、sk_receive_queue和Backlog。这些队列在数据包处理过程中扮演着重要角色,帮助提高系统性能和效率。 ... [详细]
  • 本文探讨了Linux/Unix文件系统中两种主要的权限控制方式:传统的UGO(User/Group/Others)和更为精细的ACL(Access Control List)。ACL提供了一种更灵活的权限管理方法,适用于需要对文件系统进行细粒度控制的场景。 ... [详细]
author-avatar
-鹊巢鸠占
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有