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

From: Philippe Gerum
Date: Tue Jun 21 2005 - 09:07:41 EST

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at