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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
