Re: PREEMPT_RT vs ADEOS: the numbers, part 1

[Philippe Gerum <rpm@xenomai.org>]

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.