User: Password:
|
|
Subscribe / Log in / New account

Realtime - what is it?

Realtime - what is it?

Posted Jul 19, 2006 21:47 UTC (Wed) by simlo (guest, #10866)
Parent article: Kernel Summit 2006: Realtime

The editor - along with many other people - seems to equate low latency with realtime. That is not how I view it as a realtime programmer. For me the important issue deterministic latencies. On a system based on fixed priorities, like the real-time priorities in Linux, it is important that the latency for a task running at a given priority only depends on what is running at equal or higher priority. If the OS offers that, you can use it to build a real-time system. How low the latencies are, is ofcourse important for the specific application.

Now some people at LKML claims that for a system to be hard real-time it has to be mathematically proved to be so. For me that is mixing up the issues. People can easily use Linux for other mission critical applications without having a mathematical proof it won't crash. They rely on observation and the fact that the coders consider all crashes as very important bugs. You can then also rely on Linux giving deterministic latencies by observation and if you know the coders have done what they can to avoid unbounded latencies.

The latter can be an issue. The first problem is that 95% of the Linux hackers do not care about real-time. Therefore they wont bother about making code with unbound execution inside spin-locks. The trick about turning spin-locks into mutexes helps that: The unbound code is suddenly preemptible and the higher priority real-time tasks does not have to worry. Sometimes per-cpu variables are used and protected with preempt_disable() or local_irq_disable(). All those places have to be looked at, when people want to use those subsystems in a real-time system.

The second problem is that not even all those coding on real-time systems agree on the rules! So the kernel can still get code from XYZ for real-time which turns out not to be if not properly reviewed. I have noticed stuff added to the preempt-realtime itself which is not entirely safe against Joe User. I.e. Joe User could make an evil program making the latencies very high.

Merging preempt-realtime into the main-line will be a good idea. Then Linux can compete with the dedicated RTOSes - which don't even have to care about Joe User because they typically are single user systems. But for Linux to be really successfull in doing that, someone has to specify the aims and the rules. And there has to be reviews of everything entering the kernel to see if it breaks the real-time behaviour - or at least mark it as unsafe for real-time perposes.


(Log in to post comments)

Realtime - what is it?

Posted Jul 19, 2006 23:27 UTC (Wed) by corbet (editor, #1) [Link]

Maybe I should have been clear: the realtime folks claim 20 µsec worst case response times. They are aiming for determinism, not just quickness.

Realtime - what is it?

Posted Jul 20, 2006 17:36 UTC (Thu) by nevets (subscriber, #11875) [Link]

I have to disagree about the comment about 95% of the kernel hackers don't care about real-time. Actually, being more specific, they worry about latency, not to the degree of us real-time folks, but they certainly do care. That's why there is a big push to separate out the latency-tracer patches to be merged into mainline. A lot of clean up code has been happily accepted that fixes latency problems.

This is one of the things that most of the kernel hackers agree on. No matter what you think about the RT patch, it definitely has found and was a source of a fix to numerous bugs. Some of the patches were clean ups, others fixed hard to find deadlocks, and several fixed up latency problems. So in general, the RT patch has been good to the Linux kernel in general.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds