Lines Matching refs:of

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
14 design of the Linux time(r) system before hrtimers and other building blocks
32 The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of
39        - independent of ticks (the processing is based on nanoseconds)
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
48 specific portion is reduced to the low level hardware details of the clock
72 period defined at compile time. The setup and selection of the event device
75 makes it extremely difficult to change the configuration of the system to use
77 architecture. Another implication of the current design is that it is necessary
83 event driven kernel functionalities. The goal of the clock event subsystem is
85 hardware related handling and to allow easy addition and utilization of new
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.
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
111 from the hardware level handler. This removes a lot of duplicated code from the
113 clock event devices and the assignment of timer interrupt related functionality
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.
127 The conversion of an architecture has no functional impact, but allows to
130 enabling of high resolution timers and dynamic ticks is simply provided by
132 adding the dynamic tick specific calls to the idle routine (a total of 3 lines
143 useful function. The initialization of the clock event device framework, the
149 which inform hrtimers about availability of new hardware. hrtimers validates
150 the usability of the registered clock sources and clock event devices before
156 global clock event devices. The support of such hardware would involve IPI
163 The time ordered insertion of timers provides all the infrastructure to decide
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
188 and calls update_process_times and profiling. The implementation of the hrtimer
196 separated from the tick bound timer softirq to allow accurate delivery of high
198 timers. The execution of this softirq can still be delayed by other softirqs,
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
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