Messages in this thread | | | Subject | Re: 2.6.13-rt6, ktimer subsystem | From | Thomas Gleixner <> | Date | Fri, 16 Sep 2005 00:53:39 +0200 |
| |
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
- 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/
| |