Messages in this thread | | | Date | Tue, 21 Jun 2005 18:19:31 -0700 | From | "Paul E. McKenney" <> | Subject | Re: PREEMPT_RT vs I-PIPE: the numbers, part 2 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |