Lines Matching refs:the

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:
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
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.
20 The design contains the following basic building blocks:
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
36 The main differences to the timer wheel, which holds the armed timer_list type
39        - independent of ticks (the processing is based on nanoseconds)
46 code out of the architecture-specific areas into a generic management
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
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.
56 Further information about the Generic Time Of Day framework is available in the
63 Figure #3 (OLS slides p.18) illustrates the transformation.
69 While clock sources provide read access to the monotonically increasing time
70 value, clock event devices are used to schedule the next event
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
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
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
86 clock event devices. It also minimizes the duplicated code across the
87 architectures as it provides generic functionality down to the interrupt
90 Clock event devices are registered either by the architecture dependent boot
93 clock event management decides, by using the specified property parameters, the
95 includes the distinction of per-CPU and per-system global event devices.
97 System-level global event devices are used for the Linux periodic tick. Per-CPU
101 The management layer assigns one or more of the following functions to a clock
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.
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
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.
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
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)
135 Figure #4 (OLS slides p.20) illustrates the transformation.
141 During system boot it is not possible to use the high resolution timer
143 useful function. The initialization of the clock event device framework, the
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
150 the usability of the registered clock sources and clock event devices before
152 configured for high resolution timers can run on a system which lacks the
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
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
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
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
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.
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
192 systems. This has been proved to work with the PIT on i386 and the Incrementer
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
199 but the overall latencies have been significantly improved by this separation.
201 Figure #5 (OLS slides p.22) illustrates the transformation.
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
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.
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().
230 in the idle period to make sure that jiffies are up to date and the interrupt
238 systems, where the time slice is controlled by the scheduler, variable
239 frequency profiling, and a complete removal of jiffies in the future.
242 Aside the current initial submission of i386 support, the patchset has been