OSDev.org

Greetings,

I know this is not a forum for discussing Xenomai or RTAI or Linux in particular, but I only wish to understand the reasons behind some design decisions w.r.t real time threads in an operating system.

From: http://www.xenomai.org/documentation/xe ... -rev-B.pdf

The above behaviour is to be opposed to what happens with RTAI/LXRT for instance, where threads migrating to the Linux space actually lose their real­- time priority in the same move, by inheriting the lowest priority defined by the RTAI scheduler.

I wished to understand what kind of advantages can it offer, and on a forum I found someone mentioning the following assumptions:
- Threads don't spend much time in kernel space.
- Thread in kernel space tend to hold resources that need to be released as quickly as possible.

This does make sense to me.

But then, from:
http://www.xenomai.org/documentation/xe ... -rev-B.pdf

Xenomai threads are not only able to run over the context of the highest priority domain in the pipeline (i.e. the primary domain) like kernel­based Xenomai threads, but also in the regular Linux space (i.e. the secondary domain), while still being considered as real­time by Xenomai, albeit suffering higher scheduling latencies.

Considering "Threads in kernel space tend to hold resources that need to be released as quickly as possible." what can be the reasons behind the design decision of letting the threads maintain their priority in user space in Xenomai?

What kind of advantages/disadvantages does this behavior offer w.r.t hard real time?

Please guide.

Yo:

A quick google for "Xenomai" says that it is an effort to bring a moderate amount of hard real time reliability to Linux. This is not a feasible undertaking because Linux is not a hard realtime kernel. Even though linux offers soft realtime, hard realtime is so very different from soft realtime that it would not make sense to try to augment linux to do hard realtime.

The key difference is that hard realtime is about guaranteeing time constraints, whereas soft realtime is about increasing performance, throughput, and response of "high priority" threads. While most of their research is probably very insightful, their primary goal is flawed, so their findings as applied to Linux are also flawed.

Hard real-time tasks are considered failed and unrecoverable if they are not scheduled such that their time constraints are met. Soft realtime tasks are considered "compromised in performance" if their constraints are not met. A hard realtime task that was not scheduled such that it completed its desired action within its stated time limit cannot sensibly be scheduled after the time limit because it has already failed meet its requirement.

--Peace out,
gravaera.

Thanks much for replying.

gravaera wrote:The key difference is that hard realtime is about guaranteeing time constraints, whereas soft realtime is about increasing performance, throughput, and response of "high priority" threads. While most of their research is probably very insightful, their primary goal is flawed, so their findings as applied to Linux are also flawed.

So, in nutshell you meant to say that by maintaining the same priority of real time threads in user space, they are basically attempting at not so low latencies w.r.t hard real time.
And the advantage of their approach can be (as you mentioned) increase in throughput, rather than extremely low latencies?

They are a hard real time too, but their latencies aren't too low. Is that correct?

Yo:

Well, given that Linux already has facilities for enhancing the performance of supposed "high priority" tasks, I'd say that adding a new scheduling queue or priority class that does nothing different from the queue below it would make the new queue a redundant waste of time

Also, note well that the goal of hard realtime is not to reduce latency. All of that is already covered by boosting a task's soft realtime priority. Their time would be better spent creating an improved soft realtime algorithm for Linux, as opposed to trying to implement hard realtime to cover a problem that soft realtime already (mostly) addresses.

EDIT: In other words, there is no advantage, IMHO, to their idea of trying to add hard realtime to Linux.

--Peace out,
gravaera

Some confusions:

gravaera wrote:I'd say that adding a new scheduling queue or priority class that does nothing different from the queue below it would make the new queue a redundant waste of time

In Xenomai, the priority of "Xenomai's real time threads" is always higher than Linux's kernel threads.

Xenomai gets the interrupts before Linux. Stalls Linux's kernel threads when handling interrupts.

So, doesn't this mean that they "have" implemented a hard real time which isn't present in Linux?

gravaera wrote:Also, note well that the goal of hard realtime is not to reduce latency.

Yes, of course, but preempt_rt patch of Linux is a providing a hard real time with extremely low latency (as compared to Xenomai and RTAI).

Yo:

K, consider the following: an aeroplane is flying over a mountain range and for whatever reason, it is now about to crash. There are now multiple tasks that must be run at the same time and all of them must be completed in a certain maximum amount of time. None of these tasks is more important than any other task. All of these tasks are critical to saving human lives.

For example: the "Send out SOS radio signal" task is not any more important to saving human lives than the "deploy plane-rear-end parachute" task in the overall scheme of "preserving human life". This is a hard real time environment -- the working parameters are fundamentally different. All of these tasks must be completed, period. And if any of them cannot be completed by the time the plane has crashed, we can assume that they have failed in their real-time constraints. While it is likely that the plane's radio equipment may not be damaged, what about the "deploy passenger air-bags" task? Which of the large number of tasks can you really say is "more important" than any other that needs to be executed in that critical time window?

If you deploy the air-bags after the crash, it is a waste of time; similarly, if you deploy the rear-end parachute after the crash, it is also a waste of time. If you send out the SOS-signal after the crash, it may or may not be a waste of time pending the usability of the radio gear after the crash.

Hard real time is fundamentally not about reducing latency. That is the domain of soft real time. In other words, all that Xenomai is doing is implementing an extra "soft real time" layer on top of Linux's current "soft real time", and seeing "increased response" of their "super-high-priority" threads over the normal "high priority" threads at the cost of destabilizing the rest of the system.

--Peace out,
gravaera

I did understand that. Thanks.

But, I just want a confirmation on:

In Xenomai, the priority of "Xenomai's real time threads" is always higher than Linux's kernel threads.
Xenomai gets the interrupts before Linux. Stalls Linux's kernel threads when handling interrupts.
So, doesn't this mean that they "have" implemented a hard real time which isn't present in Linux?

By the above quote I meant that if a obstacle detecting sensor of the car reports some parameters to the OS, Xenomai will get it first. Xenomai knows that this needs to be completed/dealt with before the non real time tasks of the Linux kernel, so Xenomai will stall the Linux's processings, and deal with the sensor's data (and thus prevent the crash).

So, in this way can we not say that Xenomai does offer a hard real time which Linux kernel doesn't?

Yo:

I guess you could say that it adds a measure of "harder-than-soft" realtime which may suffice for "not-so-hard" realtime environments (which is not sufficient for real "hard" realtime).

Whether or not the overhead involved in inserting an extra layer of scheduling is worth it for a market that Linux itself doesn't target, and probably won't be aiming to target anytime soon (the next 100+ years) is I suppose a justification that the developers of Xenomai will have to come up with (and probably already have).

--Peace out,
gravaera

Thanks for all your time.

Offtopic:
Not a native English speaker am I - What's all about "Yo" and "Peace out" that you write in every post?

EDIT-trial

Mostly like a "greeting and complimentary closing"; personal style more than anything else

--Peace out,
gravaera

-Alright, thanks for the clarification.-