Re: 2.6.13-rt6, ktimer subsystem

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 2005-09-15 at 15:35 -0700, George Anzinger wrote:

> > Performance is a straw man argument here. You know very well that > 90%
> > of the timers are inaccurate "timeout" timers related to I/O,
> > networking, devices. Most of those never expire (the positive feedback
> > removes the timer before expiry) and those timers have no constraint to
> > be accurate, except for the fact that they have to detect an
> > device/network problem at some time. In this case it is completely
> > irrelevant whether the timeout occurs n msecs earlier or later.
> 
> I agree, but it not accuracy that I am arguing, but cpu cycles.  Those 
> we use in the kernel are not available for the user.

The time used for recascding is neither available :). Seriously, I'm
quite sure that the rbtree for the sorting of "timers" - not "timeouts"
- will not have any relevant performance impact. If there is a faster
sorted tree around, I have no problem to use that.

> I confess I don't understand the above numbers.  What are min and max 
> and in what units?  Are you saying the large max numbers are caused by 
> the cascade?

Sorry, all units usec.

Yes. The problem is the combined base lock, which holds off interrupts
for quite a bunch of time. Daniel was experiencing this too.
 
> > - The posix timer tests run all successful, except the broken 2timertest
> > which fails on any other HRT kernel too and the sleep to long for real
> > timers when the clock is set backwards, which is easily solvable
> > (working on that).
> 
> Your mileage seems to differ from mine.  Here is what I get from ./do_test:
> The following tests failed:
> clock_nanosleeptest
> abs_timer_test
> 4-1
> clock_settimetest
> clock_gettimetest2
> 2timer_test 

Hmm. Except for the 2timer_test, where my source seems to be broken it
works here. 

> Then, on the second run, it crashed in an attempt to get the monotonic 
> clock (a divide error).  System is a dual PIII, 800Mhz.  This from the 
> rt11 patch.

Hmm, divide error. I had one of those in the early phase due to some
strange 64/32 truncation problem, which was caused by nested
inline/macros. After unmingling the problem went away.

tglx