Re: PREEMPT_RT vs ADEOS: the numbers, part 1

Philippe Gerum
2005-06-12T15:31:54Z

Sven-Thorsten Dietrich wrote:
> On Sat, 2005-06-11 at 17:44 +1000, Nick Piggin wrote:
>
>>Ingo Molnar wrote:
>>
>>>could you send me the .config you used for the PREEMPT_RT tests? Also,
>>>you used -47-08, which was well prior the current round of performance
>>>improvements, so you might want to re-run with something like -48-06 or
>>>better.
>>>
>>
>>The other thing that would be really interesting is to test latencies
>>of various other kernel functionalities in the RT kernel (eg. message
>>passing, maybe pipe or localhost read/write, signals, fork/clone/exit,
>>mmap/munmap, faulting in shared memory, or whatever else is important
>>to the RT crowd).
>>
>
>
> I have recently seen an analysis of this. It was internal to a customer,
> but I will ask whether they object to publishing it.
>
> Notably, there are naturally discrepancies between user space and kernel
> tasks. An example of this is thread-spawn benchmarks. That is relevant
> to folks who have RT code with IP to protect that must run in user
> space.
>

This said, running RT tasks in user-space is not uncommon with
nanokernel-based solutions: RTAI does this since 1999, so the "IP"
protection argument does not stand here.

There is a crucial difference between being able to run your RT stuff
under MMU protection with stringent RT guarantees, and being able to
additionally call the native Linux services with the same set of
guarantees. For this reason, keeping the regular programming model in
user-space does not depend on being able to use the kernel services in a
fully deterministic fashion.

IOW, if your RT extension is able to recycle the MMU context of any
Linux task for scheduling it in user-space without stepping on the
kernel toes, you can actually provide for both determinism and
protection (be it MMU or IP), even if you can't make the vanilla kernel
services more deterministic than they are if you happen to call them. If
you don't and always use the highly deterministic services your RT
extension provides, then the RT guarantees are always kept.

Allowing seamless and consistent dynamic transitions between the always
deterministic nanokernel context and the mostly deterministic Linux
context is one way to extend the options available to the RT application
designer. In any case, one would have to carefully select the system
calls which could be used in the application, depending on the expected
level of predictability and time accuracy; using a "pure" Linux
infrastructure or going for a mixed Linux/nanokernel environment never
breaks this invariant.

--

Philippe.