Re: [PATCH 1/2] I-pipe: Core implementation

[Philippe Gerum <rpm@xenomai.org>]

Karim Yaghmour wrote:
> Philippe Gerum wrote:
> 
>>Any objection to make the pipeline a static-only feature?
> 
> 
> FWIW, we conducted our tests with the I-pipe loaded as a module.
> Though we didn't publish that particular result as part of our
> earlier posting, we found that the price for having it loaded,
> but unused, versus not having it loaded at all made virtually
> no difference on overall system overhead. Such results would
> seem to indicate that having it as a loadable module has no
> specific advantage. Note, though, that we didn't do the test on
> all configs, just the "plain" one.
> 
> Of course the issue would be much easier to decide if you
> could provide a brief explanation as to what the difference is, in
> terms of execution path, between having it compilled as a module
> and not loaded, versus having it built-in and unused.

Having it built statically but unused by any other domain but Linux is 
basically like having local_irq_disable() and friends as out-of-line 
code, still with real hw masking, but with all interrupts going through 
the I-pipe's interrupt handler before being dispatched to the regular 
Linux handler.

OTOH, having the I-pipe as an unloaded module leaves the original 
interrupt path untouched (at least on x86), but requires a boolean check 
into each stall/unstall/test operations, and a few more (~4) in the 
interrupt path just to make sure that we are operating in real or 
virtual (i.e. pipelined) mode, IOW to check if the pipelining engine is 
engaged or not, and further decide if we should use the CPU or I-pipe 
masking ops. The other solution would have been to play the function 
pointer game in order to reach the pipelined/non-pipelined operations 
depending on the box being i-piped or not, but I was unsure of the 
impact on performances.

-- 

Philippe.