Detailed explanation of the time representation example of the Linux time subsystem

Preface

In the Linux kernel, in order to be compatible with the original code, or to comply with certain specifications, and to meet the current increasing requirements for precision, a variety of time-related data structures are implemented for different purposes:

1) jiffies and jiffies_64

The kernel uses the jiffies_64 global variable to record how many ticks have passed since the system was started. Its declaration is as follows (the code is located in kernel/time/timer.c):

__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;

EXPORT_SYMBOL(jiffies_64);

It can be seen that jiffies_64 is defined as a 64-bit unsigned integer. However, for historical reasons, the kernel source code also includes another variable called jiffies. The reference to jiffies (the code is located in include/linux/jiffies.h) is declared as:

extern u64 __cacheline_aligned_in_smp jiffies_64;
extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;

Therefore, the jiffies variable is a global variable of type unsigned long which is only 4 bytes long (32 bits) if on a 32-bit processor. However, if the processor is 64 bits long, the global variables jiffies and jiffies_64 are equivalent.

But you can't find the definition of the global variable jiffies after searching through all the code. Finally, you find the following line in the kernel link script (for the Arm64 architecture, the script is located in arch/arm64/kernel/vmlinux.lds.S):

jiffies = jiffies_64;

The secret is here. It turns out that the symbols jiffies and jiffies_64 are specified to point to the same address during linking. That is, on a 32-bit machine, the lower 4 bytes of jiffies and jiffies_64 are the same.

In general, we can directly access the jiffies global variable whether on a 32-bit or 64-bit machine, but if we want to get the jiffies_64 global variable, we need to call the get_jiffies_64 function. For 64-bit systems, the two are the same, and jiffies is declared volatile and cache-aligned, so just return jiffies directly:

static inline u64 get_jiffies_64(void)
{
 return (u64)jiffies;
}

For 32-bit systems, since 64-bit reads and writes are not atomic, the jiffies_lock read order lock is also required:

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;
}

Basically, jiffies is incremented by 1 every time a tick arrives, and the tick period HZ is configured by the kernel compilation option. In a 32-bit system, we assume that HZ is set to 250, then the period of each Tick is 4 milliseconds, and the counter will overflow after reaching the maximum value in less than 200 days. If HZ is set higher, the overflow time will be shorter. Of course, if you are running on a 64-bit system, you don't have to worry about this issue at all. Therefore, when using jiffies for time comparison, you need to use several macros that have been defined by the system:

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)

To be on the safe side, the kernel also provides a corresponding 64-bit version. These macros can effectively solve the wrapping problem, but they are not unlimited. How is this done specifically? Let's take a look at the time_after macro:

#define time_after(a,b) \
 (typecheck(unsigned long, a) && \
 typecheck(unsigned long, b) && \
 ((long)((b) - (a)) < 0))

First, do a type check on the two variables, both must be of type unsigned long. The most important thing is the following: first subtract the two unsigned long integers, then convert them into signed long integers, and then determine whether it is a negative number, that is, whether the highest bit of the 32 bits is 1.

Why can this partially solve the so-called wraparound problem? We can take an example, for simplicity, take an 8-bit unsigned integer as an example, its value range is 0 to 255 (0xFF). Assuming the current time is 250, then after 5 ticks, it will be 255, which has reached the maximum value that can be expressed. At this time, if another tick passes, that is, after 6 ticks, it will overflow and become 0. At this point, if you simply compare the two values ​​to determine which time is later, it will obviously be wrong, because the time after 6 ticks is 0, which is smaller than the current time. This problem is the so-called wraparound. However, if we subtract the two numbers first, that is, 0-250 (0-0xFA), an overflow will also occur, and the final number is exactly 6. But this is also limited, the difference between the two compared times cannot exceed half of the maximum representation range. Assume that the current time is still 250, and after 128 ticks, the time value will become 122. If the two are subtracted, the result is 122-250 (0x86-0xFA), and the subtracted number is 128. At this time, if it is converted into a signed number, it becomes a negative number, and the result is wrong.

In addition, jiffies are updated every Tick, and the Tick period is defined at compile time, so the value of jiffies can be converted into the specific amount of time that has passed, and vice versa. Therefore, the kernel provides the following conversion functions:

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 and timespec64

Timespec consists of seconds and nanoseconds and is defined as follows (the code is located in include/uapi/linux/time.h):

struct timespec {
 __kernel_time_t tv_sec;
 long tv_nsec;
};

tv_sec: Stores the number of seconds that have passed since 00:00, January 1, 1970 (UTC time). __kernel_time_t is ultimately defined as a long type, which means it is 32 bits long on a 32-bit system and 64 bits long on a 64-bit system.

tv_nsec: stores the number of nanoseconds (ns) that have passed since the last second.

Timespec also has a 64-bit extended structure, which is defined as follows (the code is located in include/linux/time64.h):

typedef __s64 time64_t;

......

struct timespec64 {
 time64_t tv_sec;
 long tv_nsec;
};

The variable definition in this structure is the same as timespec, except that the type of tv_sec must be a 64-bit unsigned number. So, on 64-bit systems, the timespec and timespec64 structures are exactly the same.

3) ktime_t

In the Linux time subsystem, ktime_t is generally used to represent time, which is defined as follows (the code is located in include/linux/ktime.h):

typedef s64 ktime_t;

It is a very simple 64-bit signed integer that represents the time unit in nanoseconds.

4) timeval

The gettimeofday and settimeofday functions use timeval as the time unit:

struct timeval {
 __kernel_time_t tv_sec;
 __kernel_suseconds_t tv_usec;
};

tv_sec: Stores the number of seconds that have passed since 00:00, January 1, 1970 (UTC time). __kernel_time_t is ultimately defined as a long type, which means it is 32 bits long on a 32-bit system and 64 bits long on a 64-bit system.

tv_usec:__kernel_suseconds_t is actually defined as a long type, which stores the number of microseconds (us) that have passed since the previous second.

Therefore, this structure is actually very similar to the timespec structure. The value stored in tv_sec is the same, and you only need to divide tv_nsec in timespec by 1000 to get tv_usec in timeval.

Summarize

This is the end of this article about the time representation of the Linux time subsystem. For more information about Linux time representation, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!