[lkml]   [2005]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.13-rt6, ktimer subsystem
Ingo Molnar wrote:
> i have released the 2.6.13-rt6 tree, which can be downloaded from the
> usual place:
> there are lots of small updates all across and there's a big feature as
> well in this release: a complete rework of the high-resolution timers
> framework, from Thomas Gleixner, called 'ktimers'.
> under the ktimer framework the HR (and posix) timers live in a separate
> domain, have their own (per-CPU) rbtree to stay scalable and
> deterministic even with a high number of timers. Another positive effect
> of the introduction of separate ktimers is that kernel/timer.c is now
> using preemptible locks again, removing the cascade() worst-case
> latency. The cleanup factor is high as well: the ktimer framework
> slashes 1300+ lines off the HRT code. See kernel/ktimer.c for details.
> the end-effect of ktimers is a much more deterministic HRT engine. The
> original merging of HR timers into the stock timer wheel was a Bad Idea
> (tm). We intend to push the ktimer subsystem upstream as well.

Well, having spent a bit of time looking at the code it appears that a
lot of the ideas we looked at and discarded (see are in this. Shame it
was all done with out reference or comment to that list, anyone on it or
even the lkml.

I DO agree that it _looks_ nicer, cleaner and so on. But there are a
lot of things we rejected in here and they really do need, at least, a
hard look.

A few of the top issues:

time in nanoseconds 64-bits, requires a divide to do much of anything
with it. Divides are slow and should be avoided if possible. This is
especially true in the embedded market.

The rbtree is a high overhead tree. I suspect performance problems
here. If it is the right answer here, then why not use it for normal
timers? A list of timers is a rather unique thing and, I think,
deserves a management structure that accounts for the fact that the
elements in the tree are perishable.

It appears that the "monotonic_clock" is being used to drive ktimers.
The "monotonic_clock" was NEVER meant to poke outside of the kernel. It
is a raw kernel clock that is only required to be monotonic with nothing
said about accuracy. It should NOT be confused with CLOCK_MONOTONIC
which is directly tied to xtime and therefor is ntp corrected.

These are only the concerns I have from having a rather quick look at
the code. I am sure that there are other issues...

George Anzinger
HRT (High-res-timers):
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-14 21:42    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean