Difference between revisions of "Kernel Timer Systems"
|Line 61:||Line 61:|
== timer API ==
== timer API ==
posix timer API
sleep, usleep and nanosleep
== time API ==
== time API ==
Revision as of 16:56, 22 October 2007
This page has links to information about the (relatively) new timer systems for the Linux kernel. The current linux kernel received a major enhancement to it's timer system (as of about 2.6.21), which solved a number of problems.
A good article on the subject is at at lwn.net: Clockevents and dyntick
- 1 Timer Wheel, Jiffies and HZ (or, the way it was)
- 2 ktimers
- 3 Dynamic ticks
- 4 timer API
- 5 time API
- 6 High Resolution Timers
- 7 Old timer wheel/jiffy replacement proposals
- 8 Timer Tick Thread - LKML July 2005
Timer Wheel, Jiffies and HZ (or, the way it was)
The original kernel timer system (called the "timer wheel) was based on incrementing a kernel-internal value (jiffies) every timer interrupt. The timer interrupt becomes the default scheduling quamtum, and all other timers are based on jiffies. The timer interrupt rate (and jiffy increment rate) is defined by a compile-time constant called HZ. Different platforms use different values for HZ. Historically, the kernel used 100 as the value for HZ, yielding a jiffy interval of 10 ms. With 2.4, the HZ value for i386 was changed to 1000, yeilding a jiffy interval of 1 ms. Recently (2.6.13) the kernel changed HZ for i386 to 250. (1000 was deemed too high).
Ingo Molnar's explanation of timer wheel performance
Ingo Molnar did an in-depth explanation about the performance of the current "timer wheel" implementation of timers. This was part of a series of messages trying to justify the addition of ktimers (which have different characteristics).
Material needs rework
A bunch of material in this section needs to be created or expanded to take into account the new ktimer system by Thomas Gleixner.
- See the Clockevents and dyntick LNW.net article
The configuration option is: CONFIG_NO_HZ
Prompt is: Tickless System (Dynamic Ticks), on the Kernel Features configuration menu.
How to tell if dynamic ticks is supported on your kernel:
You can look at the timer interrupts and compare to jiffies:
cat /proc/interrupts | grep -i time sleep 10 cat /proc/interrupts | grep -i time
Then, cat /proc/timer_stats, and it gives and average events/sec at the end as well so you get a rough idea of system activity.
You can use powertop on embedded processors, but in order to get a clean display from it, you need an ncurses lib with wide-char support. (From Kevin Hilman, Oct 2007)
- interval timers
- posix timer API
- sleep, usleep and nanosleep
High Resolution Timers
See High Resolution Timers, which describe sub-jiffy timers.
Old timer wheel/jiffy replacement proposals
Jun Sun's "tock" proposal
This systems replaces jiffies and xtime with tocks (arch-dependent), mtime (monotonic time) and wtime (wall time), and proposes a strategy for migrating to that.
In 2005, John Stultz proposed changes to the timers to use a 64-bit nanosecond value as the base. He did a presentation and BOF at OLS 2005. (It should be available online)
Timer Tick Thread - LKML July 2005
There was a very long thread about timers, jiffies, and related subjects in July of 2005 on the kernel mailing list.
The title was: "Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt"
Linus said jiffies is not going away
- still need 32-bit counter, shouldn't be real-time value (too much overhead to calculate) - high-res timers shouldn't be sub-HZ, but instead, HZ should be high and timer tick should not be 1:1 with HZ - in other words, have HZ be high (like 2K), have the timer interrupt fire off at some lower frequency, and increment jiffies by more than one on each interrupt. - rationale for this is to keep a single sub-system
Arjan had good points about coalescing low-res timers
- 3 use cases: - low res timeouts - high res timer for periodic absolute wakeup (wake up every 10 ms, whether last one was late or nt - high res timer for periodic relative wakeup (wake up 10 ms from now)