This is a major rework of the former ktimer subsystem. It replaces the
ktimer patch series and drops the ktimeout series completely.
A broken out series is available from
http://www.tglx.de/projects/ktimers/patches-2.6.15-rc5-hrtimer.tar.bz2
1. Naming
After the extensive discussions on LKML, Andrew Morton suggested
"hrtimer" and we picked it up. While the hrtimer subsystem does not
offer high-resolution clock sources just yet, the subsystem can be
easily extended with high-resolution clock capabilities. The rework of
the ktimer-hrt patches is the next step.
2. More simplifications
We worked through the subsystem and its users and further reduced the
implementation to the basic required infrastructure and generally
streamlined it. (We did this with easy extensibility for the high
resolution clock support still in mind, so we kept some small extras
around.)
The new .text overhead (on x86) we believe speaks for itself:
text data bss dec hex filename
2468380 547212 155164 3170756 3061c4 vmlinux-2.6.15-rc2
2469996 548016 155164 3173176 306b38 vmlinux-ktimer-rc5-mm1
2468164 547508 155100 3170772 3061d4 vmlinux-hrtimer
While it was +1616 bytes before, it's -216 bytes now. This also gives a
new justification for hrtimers: it reduces .text overhead ;-) [ There's
still some .data overhead, but it's acceptable at 0.1%.]
On 64-bit platforms such as x64 there are even more .text savings:
text data bss dec hex filename
3853431 914316 403880 5171627 4ee9ab vmlinux-x64-2.6.15-rc5
3852407 914548 403752 5170707 4ee613 vmlinux-x64-hrtimer
(due to the compactness of 64-bit ktime_t ops)
Other 32-bit platforms (arm, ppc) have a much smaller .text
hrtimers footprint now too.
3. Fixes
The last splitup of ktimers resulted in a bug in the overrun accounting.
This bug is now fixed and the code verified for correctness.
4. Rounding
We looked at the runtime behaviour of vanilla, ktimers and ptimers to
figure out the consequences for applications in a more detailed way.
The rounding of time values and intervals leads to rather unpredictible
results which deviates of the current mainline implementation
significantly and introduces unpredictible behaviour vs. the timeline.
After reading the Posix specification again, we came to the conclusion
that it is possible to do no rounding at all for the ktime_t values, and
to still ensure that the timer is not delivered early.
".. and that timers must wait for the next clock tick after the
theoretical expiration time, to ensure that a timer never returns too
soon. Note also that the granularity of the clock may be significantly
coarser than the resolution of the data format used to set and get time
and interval values. Also note that some implementations may choose to
adjust time and/or interval values to exactly match the ticks of the
underlying clock."
Which allows the already discussed part of the spec to be interpreted
differently:
"Time values that are between two consecutive non-negative integer
multiples of the resolution of the specified timer shall be rounded up
to the larger multiple of the resolution. Quantization error shall not
cause the timer to expire earlier than the rounded time value."
The rounding of the time value i.e. the expiry time itself must be
rounded to the next clock tick, to ensure that a timer never expires
early.
Thomas, Ingo
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
