yodaiken@fsmlabs.com wrote:
> I agree that you found a bug, I disagree that you will ever get 100%
> timing correctness from Linux except at the cost of making the kernel
> unmaintainable.
I agree that 100% timing correctness is difficult, and the best way is
undoubtedly one or two simple things which must be done right. RTLinux
for example (on the platforms which RTLinux supports).
Otoh, with the low latency patches and some long measurements, we can
demonstrate 99.999% (or whatever it is) timing correctness. Those tests
found things like the missing cli in the idle loop, and the
ret_from_sys_call race with need_resched.
So, with the things that show up in tests fixed, it's safe to use this
for soft RT including sensitive things like audio, provided you stick to
the reasonably tested drivers.
I guess that means that the current->need_resched problem, which hasn't
shown up in tests, does not need to be fixed. (But it would probably
clean up the scheduler to do so anyway).
> Furthermore, if you do similar timing tests on VxWorks, Win-CE, and
> etc, I bet you will find that 100 milliseconds is not impossible.
> Note that even QNX quotes "typical" interrupt latency times.
There's nothing wrong with doing _better_ than the competition.
have a nice day,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:34 EST