Driver porting: Timekeeping changes
| This article is part of the LWN Porting Drivers to 2.6 series. |
Internal clock frequency
One change which shouldn't be problematic for most code is the change in the internal clock rate on the x86 architecture. In previous kernels, HZ was 100; in 2.6 it has been bumped up to 1000. If your code makes any assumptions about what HZ really was (or, by extension, what jiffies really signified), you may have to make some changes now. For what it's worth, as of 2.6.0-test9, the default values of HZ in the mainline kernel source (which sometimes lags the architecture-specific trees) is as follows: Alpha: 1024/1200; ARM: 100/128/200/1000; CRIS: 100; i386: 1000; IA-64: 1024; M68K: 100; M68K-nommu: 50-1000; MIPS: 100/128/1000; MIPS64: 100; PA-RISC: 100/1000; PowerPC32: 100; PowerPC64: 1000; S/390: 100; SPARC32: 100; SPARC64: 100; SuperH: 100/1000; UML: 100; v850: 24-100; x86-64: 1000.
Kernel time variables
When the internal clock rate on a 32-bit system is set to 1000, the classic 32-bit jiffies variable will overflow in just over 49 days. Overflows could always happen on systems with a long uptime, but, when it took well over a year of uptime, it was a relatively rare occurrence - even on Linux systems. It is not uncommon at all, however, for a system to be up for more than 50 days. In most cases, having jiffies wrap around is not a real problem; it can be inconvenient for tasks like process accounting, however. So the 2.5 kernel has a new counter called jiffies_64. With 64 bits to work with, jiffies_64 will not wrap around in a time frame that need concern most of us - at least until some future kernel starts using a gigahertz internal clock.For what it's worth, on most architectures, the classic, 32-bit jiffies variable is now just the least significant half of jiffies_64.
Note that, on 32-bit systems, a 64-bit jiffies value raises concurrency issues. It is deliberately not declared as a volatile value (for performance reasons), so the possibility exists that code like:
u64 my_time = jiffies_64;
could get an inconsistent version of the variable, where the top and bottom halves do not match. To avoid this possibility, code accessing jiffies_64 should use xtime_lock, which is the new seqlock type as of 2.5.60. In most cases, though, it will be easier to just use the convenience function provided by the kernel:
#include <linux/jiffies.h>
u64 my_time = get_jiffies_64();
Users of the internal xtime variable will notice a couple of similar changes. One is that xtime, too, is now protected by xtime_lock (as it is in 2.4 as of 2.4.10), so any code which plays around with disabling interrupts or such before accessing xtime will need to change. The best solution is probably to use:
struct timespec current_kernel_time(void);
which takes care of locking for you. xtime also now is a struct timespec rather than struct timeval; the difference being that the sub-second part is called tv_nsec, and is in nanoseconds.
Timers
The kernel timer interface is essentially unchanged since 2.4, with one exception. The new function:
void add_timer_on(struct timer_list *timer, int cpu);
will cause the timer function to run on the given CPU with the expiration time hits.
Delays
The 2.5 kernel includes a new macro ndelay(), which delays for a given number of nanoseconds. It can be useful for interactions with hardware which insists on very short delays between operations. On most architectures, however, ndelay(n) is equal to udelay(1) for waits of less than one microsecond.