Re: PREEMPT_RT vs I-PIPE: the numbers, part 2

[Karim Yaghmour]

Paul E. McKenney wrote:
> It looks to me that I-PIPE is an example of a "nested OS", with
> Linux nested within the I-PIPE functionality. 

Sorry, the I-pipe is likely in the "none-of-the-above" category. It's
actually not much of a category itself. For one thing, it's clearly
not an RTOS in any sense of the word.

The I-pipe is just a layer that allows multiple pieces of code to
share an interrupt stream in a prioritized fashion. It doesn't
schedule anything or provide any sort of abstraction whatsoever.
Your piece of code just gets a spot in the pipeline and receives
interrupts accordingly. Not much nesting there. It's just a new
feature in Linux.

Have a look at the patches and description posted by Philippe last
Friday for more detail.

> One could take
> the RTAI-Fusion approach, but this measurement is of I-PIPE
> rather than RTAI-Fusion, right?  (And use of RTAI-Fusion might
> or might not change these results significantly, just trying to
> make sure I understand what these specific tests apply to.)

That's inconsequential. Whether Fusion is loaded or not doesn't
preclude a loaded driver to have a higher priority than
Fusion itself and therefore continue receiving interrupt even if
Fusion itself has disabled interrupts ...

The loading of Fusion would change nothing to these measurements.

> Also, if I understand correctly, the interrupt latency measured
> is to the Linux kernel running within I-PIPE, rather than to I-PIPE
> itself.  Is this the case, or am I confused?

What's being measured here is a loadable module that allocates an
spot in the ipipe that has higher priority than Linux and puts
itself there. Therefore, regardless of what other piece of code
in the kernel disables interrupts, that specific driver still
has its registered ipipe handler called deterministically ...

Don't know, but from the looks of it we're not transmitting on
the same frequency ...

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@xxxxxxxxxxx || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/