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

[Paul E. McKenney]

On Mon, Jun 20, 2005 at 10:29:32PM -0400, Karim Yaghmour wrote:
> 
> 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.

It is a bit of an edge case for any of the categories.

> > 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.

OK...

> > 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 ...

Probably just my not fully understanding I-PIPE (to say nothing of
not fully understanding your test setup!), but I would have expected
I-PIPE to be able to get somewhere in the handfuls of microseconds of
interrupt latency.  Looks like it prevents Linux from ever disabling
real interrupts -- my first guess after reading your email was that
Linux was disabling real interrupts and keeping I-PIPE from getting
there in time.

						Thanx, Paul
-
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/