On Mon, 12 Jun 2006, Lee Revell wrote:
On Mon, 2006-06-12 at 11:12 +0100, Felix Oxley wrote:
(Regarding Hard Real Time, my understanding is that that depends on a
_guarantee_ that the system will always be able to produce the
'result' within the required interval. Ingo's -rt patches may give
exceedingly good responsiveness but they offer no guarantees, so they
cannot be considered Hard Real Time)
The -rt kernel is capable of hard realtime, modulo any bugs, but no one
has yet done an analysis of the few non-preemptible code paths to
determine what guarantees it can make.
For me a "hard real time system" is one where a missing a deadline is a
bug just as well as having a stray pointer is a bug. Therefore any code
running non-preemptible and not being bound is a bug. In fact you have to
consider all code running at equal and higher priority than your RT
application - and do remember that PI can move tasks up in priority as well!
One may ask: What is bounded? The plist is an examble where
operations are "bounded" mathematically speaking, but in practise one
will never come even close to that bound. It is therefore very unlikely
that you hit the worst case behaviour in a lab test before deploying your
system - and that is very unfortunate :-(
I have, in another place, made a real priority heap, which operates in
O(log N), N being the number of elements. N can in principle be very big
- but it is limited to the amount of elements in the system (which was
static for the given application) and that is certainly limited to the
amount of memory of the system. And log 1G is still only 9 compared to
log 100 which is 2. Thus _in practice_ something O(log N) is can be
considered bounded and is more testabl, i.e. you can come closer to the
worst case behaviour in a lab test.
Which OSes, by the way, makes these mathematically guarentees? The hard
realtime OS I work with at work certainly does _not_ give such. Yes, they
do in the sales material, and the core of the OS does have a certification
for safety critical systems. But I can still find exambles of unbounded
code. The mutexes, forinstance, does not use plists and thus adding a
waiter on a mutex is not a bounded operation, _theoretically_ speaking. A
lot of the drivers and platform specific code are really bad. But the
worst is that it doesn't implement priority inheritance correctly: It
leaves a thread boosted until it releases the last mutex held. Therefore,
something you considered low priority, non-RT, code can suddenly run at
high priority!
But then again: That is an _embedded_ OS. We should in principle have
control over _all_ the code and therefore should be able to avoid the
almost theoretical pitfalls of unbounded code.
Linux is supposed to be a general perpose OS. I.e. not priviliged users
can run whatever code they want with normal priority (SCHED_OTHER) and the
system should still be hard realtime! Therefore Linux has to be implemented
even without the theoretical unbounded code.
When I compare the state of preempt-realtime and the RTOS used at work, I
would say preempt-realtime does pretty well. Especially the better
priority inheritance implementation and the MMU support makes it far
better at shielding the RT application from the arbitrary non-RT code.
With the RTOS you have to be sure that every piece of code running on the
system behaves correctly. With preempt-realtime Linux you "only" have to
thrust the kernel and your RT application itself.
Esben
Lee
-
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/
-
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
