About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / timers / highres.txt




Custom Search

Based on kernel version 3.13. Page generated on 2014-01-20 22:04 EST.

1	High resolution timers and dynamic ticks design notes
2	-----------------------------------------------------
3	
4	Further information can be found in the paper of the OLS 2006 talk "hrtimers
5	and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
6	be found on the OLS website:
7	http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf
8	
9	The slides to this talk are available from:
10	http://tglx.de/projects/hrtimers/ols2006-hrtimers.pdf
11	
12	The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the
13	changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the
14	design of the Linux time(r) system before hrtimers and other building blocks
15	got merged into mainline.
16	
17	Note: the paper and the slides are talking about "clock event source", while we
18	switched to the name "clock event devices" in meantime.
19	
20	The design contains the following basic building blocks:
21	
22	- hrtimer base infrastructure
23	- timeofday and clock source management
24	- clock event management
25	- high resolution timer functionality
26	- dynamic ticks
27	
28	
29	hrtimer base infrastructure
30	---------------------------
31	
32	The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of
33	the base implementation are covered in Documentation/timers/hrtimers.txt. See
34	also figure #2 (OLS slides p. 15)
35	
36	The main differences to the timer wheel, which holds the armed timer_list type
37	timers are:
38	       - time ordered enqueueing into a rb-tree
39	       - independent of ticks (the processing is based on nanoseconds)
40	
41	
42	timeofday and clock source management
43	-------------------------------------
44	
45	John Stultz's Generic Time Of Day (GTOD) framework moves a large portion of
46	code out of the architecture-specific areas into a generic management
47	framework, as illustrated in figure #3 (OLS slides p. 18). The architecture
48	specific portion is reduced to the low level hardware details of the clock
49	sources, which are registered in the framework and selected on a quality based
50	decision. The low level code provides hardware setup and readout routines and
51	initializes data structures, which are used by the generic time keeping code to
52	convert the clock ticks to nanosecond based time values. All other time keeping
53	related functionality is moved into the generic code. The GTOD base patch got
54	merged into the 2.6.18 kernel.
55	
56	Further information about the Generic Time Of Day framework is available in the
57	OLS 2005 Proceedings Volume 1:
58	http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf
59	
60	The paper "We Are Not Getting Any Younger: A New Approach to Time and
61	Timers" was written by J. Stultz, D.V. Hart, & N. Aravamudan.
62	
63	Figure #3 (OLS slides p.18) illustrates the transformation.
64	
65	
66	clock event management
67	----------------------
68	
69	While clock sources provide read access to the monotonically increasing time
70	value, clock event devices are used to schedule the next event
71	interrupt(s). The next event is currently defined to be periodic, with its
72	period defined at compile time. The setup and selection of the event device
73	for various event driven functionalities is hardwired into the architecture
74	dependent code. This results in duplicated code across all architectures and
75	makes it extremely difficult to change the configuration of the system to use
76	event interrupt devices other than those already built into the
77	architecture. Another implication of the current design is that it is necessary
78	to touch all the architecture-specific implementations in order to provide new
79	functionality like high resolution timers or dynamic ticks.
80	
81	The clock events subsystem tries to address this problem by providing a generic
82	solution to manage clock event devices and their usage for the various clock
83	event driven kernel functionalities. The goal of the clock event subsystem is
84	to minimize the clock event related architecture dependent code to the pure
85	hardware related handling and to allow easy addition and utilization of new
86	clock event devices. It also minimizes the duplicated code across the
87	architectures as it provides generic functionality down to the interrupt
88	service handler, which is almost inherently hardware dependent.
89	
90	Clock event devices are registered either by the architecture dependent boot
91	code or at module insertion time. Each clock event device fills a data
92	structure with clock-specific property parameters and callback functions. The
93	clock event management decides, by using the specified property parameters, the
94	set of system functions a clock event device will be used to support. This
95	includes the distinction of per-CPU and per-system global event devices.
96	
97	System-level global event devices are used for the Linux periodic tick. Per-CPU
98	event devices are used to provide local CPU functionality such as process
99	accounting, profiling, and high resolution timers.
100	
101	The management layer assigns one or more of the following functions to a clock
102	event device:
103	      - system global periodic tick (jiffies update)
104	      - cpu local update_process_times
105	      - cpu local profiling
106	      - cpu local next event interrupt (non periodic mode)
107	
108	The clock event device delegates the selection of those timer interrupt related
109	functions completely to the management layer. The clock management layer stores
110	a function pointer in the device description structure, which has to be called
111	from the hardware level handler. This removes a lot of duplicated code from the
112	architecture specific timer interrupt handlers and hands the control over the
113	clock event devices and the assignment of timer interrupt related functionality
114	to the core code.
115	
116	The clock event layer API is rather small. Aside from the clock event device
117	registration interface it provides functions to schedule the next event
118	interrupt, clock event device notification service and support for suspend and
119	resume.
120	
121	The framework adds about 700 lines of code which results in a 2KB increase of
122	the kernel binary size. The conversion of i386 removes about 100 lines of
123	code. The binary size decrease is in the range of 400 byte. We believe that the
124	increase of flexibility and the avoidance of duplicated code across
125	architectures justifies the slight increase of the binary size.
126	
127	The conversion of an architecture has no functional impact, but allows to
128	utilize the high resolution and dynamic tick functionalities without any change
129	to the clock event device and timer interrupt code. After the conversion the
130	enabling of high resolution timers and dynamic ticks is simply provided by
131	adding the kernel/time/Kconfig file to the architecture specific Kconfig and
132	adding the dynamic tick specific calls to the idle routine (a total of 3 lines
133	added to the idle function and the Kconfig file)
134	
135	Figure #4 (OLS slides p.20) illustrates the transformation.
136	
137	
138	high resolution timer functionality
139	-----------------------------------
140	
141	During system boot it is not possible to use the high resolution timer
142	functionality, while making it possible would be difficult and would serve no
143	useful function. The initialization of the clock event device framework, the
144	clock source framework (GTOD) and hrtimers itself has to be done and
145	appropriate clock sources and clock event devices have to be registered before
146	the high resolution functionality can work. Up to the point where hrtimers are
147	initialized, the system works in the usual low resolution periodic mode. The
148	clock source and the clock event device layers provide notification functions
149	which inform hrtimers about availability of new hardware. hrtimers validates
150	the usability of the registered clock sources and clock event devices before
151	switching to high resolution mode. This ensures also that a kernel which is
152	configured for high resolution timers can run on a system which lacks the
153	necessary hardware support.
154	
155	The high resolution timer code does not support SMP machines which have only
156	global clock event devices. The support of such hardware would involve IPI
157	calls when an interrupt happens. The overhead would be much larger than the
158	benefit. This is the reason why we currently disable high resolution and
159	dynamic ticks on i386 SMP systems which stop the local APIC in C3 power
160	state. A workaround is available as an idea, but the problem has not been
161	tackled yet.
162	
163	The time ordered insertion of timers provides all the infrastructure to decide
164	whether the event device has to be reprogrammed when a timer is added. The
165	decision is made per timer base and synchronized across per-cpu timer bases in
166	a support function. The design allows the system to utilize separate per-CPU
167	clock event devices for the per-CPU timer bases, but currently only one
168	reprogrammable clock event device per-CPU is utilized.
169	
170	When the timer interrupt happens, the next event interrupt handler is called
171	from the clock event distribution code and moves expired timers from the
172	red-black tree to a separate double linked list and invokes the softirq
173	handler. An additional mode field in the hrtimer structure allows the system to
174	execute callback functions directly from the next event interrupt handler. This
175	is restricted to code which can safely be executed in the hard interrupt
176	context. This applies, for example, to the common case of a wakeup function as
177	used by nanosleep. The advantage of executing the handler in the interrupt
178	context is the avoidance of up to two context switches - from the interrupted
179	context to the softirq and to the task which is woken up by the expired
180	timer.
181	
182	Once a system has switched to high resolution mode, the periodic tick is
183	switched off. This disables the per system global periodic clock event device -
184	e.g. the PIT on i386 SMP systems.
185	
186	The periodic tick functionality is provided by an per-cpu hrtimer. The callback
187	function is executed in the next event interrupt context and updates jiffies
188	and calls update_process_times and profiling. The implementation of the hrtimer
189	based periodic tick is designed to be extended with dynamic tick functionality.
190	This allows to use a single clock event device to schedule high resolution
191	timer and periodic events (jiffies tick, profiling, process accounting) on UP
192	systems. This has been proved to work with the PIT on i386 and the Incrementer
193	on PPC.
194	
195	The softirq for running the hrtimer queues and executing the callbacks has been
196	separated from the tick bound timer softirq to allow accurate delivery of high
197	resolution timer signals which are used by itimer and POSIX interval
198	timers. The execution of this softirq can still be delayed by other softirqs,
199	but the overall latencies have been significantly improved by this separation.
200	
201	Figure #5 (OLS slides p.22) illustrates the transformation.
202	
203	
204	dynamic ticks
205	-------------
206	
207	Dynamic ticks are the logical consequence of the hrtimer based periodic tick
208	replacement (sched_tick). The functionality of the sched_tick hrtimer is
209	extended by three functions:
210	
211	- hrtimer_stop_sched_tick
212	- hrtimer_restart_sched_tick
213	- hrtimer_update_jiffies
214	
215	hrtimer_stop_sched_tick() is called when a CPU goes into idle state. The code
216	evaluates the next scheduled timer event (from both hrtimers and the timer
217	wheel) and in case that the next event is further away than the next tick it
218	reprograms the sched_tick to this future event, to allow longer idle sleeps
219	without worthless interruption by the periodic tick. The function is also
220	called when an interrupt happens during the idle period, which does not cause a
221	reschedule. The call is necessary as the interrupt handler might have armed a
222	new timer whose expiry time is before the time which was identified as the
223	nearest event in the previous call to hrtimer_stop_sched_tick.
224	
225	hrtimer_restart_sched_tick() is called when the CPU leaves the idle state before
226	it calls schedule(). hrtimer_restart_sched_tick() resumes the periodic tick,
227	which is kept active until the next call to hrtimer_stop_sched_tick().
228	
229	hrtimer_update_jiffies() is called from irq_enter() when an interrupt happens
230	in the idle period to make sure that jiffies are up to date and the interrupt
231	handler has not to deal with an eventually stale jiffy value.
232	
233	The dynamic tick feature provides statistical values which are exported to
234	userspace via /proc/stats and can be made available for enhanced power
235	management control.
236	
237	The implementation leaves room for further development like full tickless
238	systems, where the time slice is controlled by the scheduler, variable
239	frequency profiling, and a complete removal of jiffies in the future.
240	
241	
242	Aside the current initial submission of i386 support, the patchset has been
243	extended to x86_64 and ARM already. Initial (work in progress) support is also
244	available for MIPS and PowerPC.
245	
246		  Thomas, Ingo
247	
248	
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.