Messages in this thread | | | Date | Wed, 14 Sep 2005 12:38:58 -0700 | From | George Anzinger <> | Subject | Re: 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: > > http://redhat.com/~mingo/realtime-preempt/ > > 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 high-res-timers-discourse@lists.sourceforge.net) 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 george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |