Linux Kernel Architecture

Chapter 15: Time Management

calc_load

do_time

jiffies_64++

update_times

update_wall_time

Figure 15-5: Code flow diagram for

do_time.

For historical reasons, the kernel sources also include another time base.jiffiesis a variable of the
unsigned longtype and is therefore only 4 bytes long on 32-bit processors, and this corresponds to 32
and not 64 bits. This causes a problem. After a longer system uptime, the counter reaches its maximum
value and must be reset to 0. Given a timer frequency of 100 Hz, this situation would arise after just less
than 500 days, and correspondingly earlier for higherHZsettings.^5 When a 64-bit data type is used, the
problem never occurs because uptimes of 10^12 days are a little utopian, even for a very stable kernel such
as Linux.

The kernel uses a trick to prevent efficiency losses when converting between the two different time bases.
jiffiesandjiffies_64match in their less significant bits and therefore point to the same memory
location or the same register. To achieve this, the two variables are declared separately, but the linker
script used to bind the final kernel binary specifies thatjiffiesequates to the 4 less significant bytes
ofjiffies_64, where either the first or last 4 bytes must be used depending on the endianness of the
underlying architecture. The two variables are synonymous on 64-bit machines.

Caution: Times specified by jiffies and thejiffiesvariable itself require some special attention. The

peculiarities are discussed in Section 15.2.2 immediately below.

The remaining actions that must be performed at each timer interrupt are delegated byupdate_times:

❑ update_wall_timeupdates the wall time that specifies how long the system has already been

up and running. While this information is also roughly provided by the jiffies mechanism, the

wall clock reads the time from the current time source and updates the wall clock accordingly. In

contrast to the jiffies mechanism, the wall clock uses a human readable format (nanoseconds) to

represent the current time.

❑ calc_loadupdates the system load statistics that specify how many tasks have on average been

waiting on the run queue in a ready-to-run state during the last 1, 5, and, 15 minutes. This status

can be output using, for example, thewcommand.

(^5) Most computers do not, of course, run uninterruptedly for so long, which is why the problem might appear to be somewhat
marginal at first glance. However, there are some applications — for instance, servers in embedded systems — in which uptimes of
this magnitude can easily be achieved. In such situations it must be ensured that the time base functions reliably.
During the development of 2.5, a patch was integrated to cause the jiffies value to wrap around 5 minutes after system boot. Potential
problems can, therefore, be found quickly without waiting for years for wraparound to occur.