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 [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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |