Lines Matching +full:quality +full:- +full:of +full:- +full:service

5 Further information can be found in the paper of the OLS 2006 talk "hrtimers
6 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
8 https://www.kernel.org/doc/ols/2006/ols2006v1-pages-333-346.pdf
11 http://www.cs.columbia.edu/~nahum/w6998/papers/ols2006-hrtimers-slides.pdf
15 design of the Linux time(r) system before hrtimers and other building blocks
23 - hrtimer base infrastructure
24 - timeofday and clock source management
25 - clock event management
26 - high resolution timer functionality
27 - dynamic ticks
31 ---------------------------
33 The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of
40 - time ordered enqueueing into a rb-tree
41 - independent of ticks (the processing is based on nanoseconds)
45 -------------------------------------
47 John Stultz's Generic Time Of Day (GTOD) framework moves a large portion of
48 code out of the architecture-specific areas into a generic management
50 specific portion is reduced to the low level hardware details of the clock
51 sources, which are registered in the framework and selected on a quality based
58 Further information about the Generic Time Of Day framework is available in the
70 ----------------------
75 period defined at compile time. The setup and selection of the event device
78 makes it extremely difficult to change the configuration of the system to use
80 architecture. Another implication of the current design is that it is necessary
81 to touch all the architecture-specific implementations in order to provide new
86 event driven kernel functionalities. The goal of the clock event subsystem is
88 hardware related handling and to allow easy addition and utilization of new
91 service handler, which is almost inherently hardware dependent.
95 structure with clock-specific property parameters and callback functions. The
97 set of system functions a clock event device will be used to support. This
98 includes the distinction of per-CPU and per-system global event devices.
100 System-level global event devices are used for the Linux periodic tick. Per-CPU
104 The management layer assigns one or more of the following functions to a clock
107 - system global periodic tick (jiffies update)
108 - cpu local update_process_times
109 - cpu local profiling
110 - cpu local next event interrupt (non periodic mode)
112 The clock event device delegates the selection of those timer interrupt related
115 from the hardware level handler. This removes a lot of duplicated code from the
117 clock event devices and the assignment of timer interrupt related functionality
122 interrupt, clock event device notification service and support for suspend and
125 The framework adds about 700 lines of code which results in a 2KB increase of
126 the kernel binary size. The conversion of i386 removes about 100 lines of
127 code. The binary size decrease is in the range of 400 byte. We believe that the
128 increase of flexibility and the avoidance of duplicated code across
129 architectures justifies the slight increase of the binary size.
131 The conversion of an architecture has no functional impact, but allows to
134 enabling of high resolution timers and dynamic ticks is simply provided by
136 adding the dynamic tick specific calls to the idle routine (a total of 3 lines
143 -----------------------------------
147 useful function. The initialization of the clock event device framework, the
153 which inform hrtimers about availability of new hardware. hrtimers validates
154 the usability of the registered clock sources and clock event devices before
160 global clock event devices. The support of such hardware would involve IPI
167 The time ordered insertion of timers provides all the infrastructure to decide
169 decision is made per timer base and synchronized across per-cpu timer bases in
170 a support function. The design allows the system to utilize separate per-CPU
171 clock event devices for the per-CPU timer bases, but currently only one
172 reprogrammable clock event device per-CPU is utilized.
176 red-black tree to a separate double linked list and invokes the softirq
180 context. This applies, for example, to the common case of a wakeup function as
181 used by nanosleep. The advantage of executing the handler in the interrupt
182 context is the avoidance of up to two context switches - from the interrupted
187 switched off. This disables the per system global periodic clock event device -
190 The periodic tick functionality is provided by an per-cpu hrtimer. The callback
192 and calls update_process_times and profiling. The implementation of the hrtimer
200 separated from the tick bound timer softirq to allow accurate delivery of high
202 timers. The execution of this softirq can still be delayed by other softirqs,
209 -------------
211 Dynamic ticks are the logical consequence of the hrtimer based periodic tick
212 replacement (sched_tick). The functionality of the sched_tick hrtimer is
215 - hrtimer_stop_sched_tick
216 - hrtimer_restart_sched_tick
217 - hrtimer_update_jiffies
243 frequency profiling, and a complete removal of jiffies in the future.
246 Aside the current initial submission of i386 support, the patchset has been