Jan Kiszka wrote:
Dmitry Adamushko wrote:

On Monday 31 October 2005 16:04, you wrote:

Dmitry Adamushko wrote:

It seems to me now, that some parts of the hal will be involved
(rthal_irq_request/release()) since the nucleus itself doesn't keep track
of registered irqs.

That's true. And it also raises another question to me: why do we have
those two different IRQ models?

The HAL only one handler per IRQ which get called with the triggering
IRQ number. That handler will call the nucleus with an attached cookie.
And on the other side is the nucleus which works with a xnintr_t per
IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
rescheduling, etc.

I'm asking as this abstraction adds one trampoline call (at HAL level),
thus may lead to more I-cache misses. Isn't it worth considering some
HAL mechanisms based on more #defines and static inlines in this regard?

Let's take a look at what we have got currently:

[1]     ipipe_domain::irqs[IPIPE_NR_IRQS]       [ADEOS-IPIPE]

the handler is defined as void (*handler)(unsigned irq);

in our case, this is rthal_irq_trampoline() [2] , but can be different for some other cases;

[2]     rthal_irq_trampoline()                          [HAL]

struct rthal_realtime_irq[IPIPE_NR_IRQS]

the handler is defined as void (*handler)(unsigned irq, void *cookie);

this one normally does a simple thing, just calls xnintr_irq_handler() [3] as you have mentioned before.

[3]     xnintr_irq_handler()                            [nucleus]

this routine calls a certain user's ISR as well as handles some nucleus-specific chores (re-scheduling, etc.)

[4]     user's ISR                                              [user driver]

does user-specific things

Well, [3] is necessary anyway since some nucleus-related chores must be done and this is a correct layer for that (e.g. [2] knows nothing about scheduling).

What can be theoretically merged is [1] + [2] (errr... I said theoretically, it's still not the case to kill me for just having said that :o). To this end, ipipe_domain should be extended in order to contain all the fields of [2]::struct rthal_realtime_irq (at least, handler(irq, cookie) + cookie). btw, ipipe_domain::irqs may even contain a pointer to the slightly modified xnintr_t structure (which is really e.g. a circular list) that may be passed as "cockie" to the xnintr_irq_handler().

The analogy is irq_desc_t vs. irqaction structures in Linux.

This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly without the [2] layer.

But that change looks quite invasive to me so far since ipipe_domain::irqs::handler(irq - with a single parameter) is used all over the map.

In our case, the relation between xnintr_irq_handler() and rthal_irq_trampoline() is 1:1. The first one does much more things that the second one which is really almost a pure redirection layer. Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under high irq load. In this case, I guess, rthal_irq_trampoline() will be in cache as well (since it's really small) and the overhead is only about having one array indexing op. and issuing a call via a pointer to the function (xnintr_irq_handler() in our case). Do you think that really gives a significant overhead? Well, maybe so. I'm not a profie here anyway...

...compared to the usefulness I still have to understand - yes.

Other option: what about merging [2] into [3], i.e. let
xnintr_irq_handler deal with the translation IRQ number -> cookie?

That's an option, yes. The other one being to teach Adeos to pass an additional cookie, but in such a case, only the i-pipe series would be upgraded to allow that, which would be a bit rude to people still currently relying on the legacy oldgen patches for running Xenomai. This said, at some point in time, upgrading will be necessary though.

Philippe, I guess your wisdom is required here. Are we missing some
important point in your design right now?

Mmm, for the wisdom thing, please see there: http://fr.wikipedia.org/wiki/Mahatma_Gandhi

For the design issue, I agree that the initial trampoline is just a waste of cache lines and cycles. The only thing to keep in mind is to preserve a sensible layering so that the whole thing is still able to run over the event-driven simulation engine we have, but AFAICS, fixing the xnarch layer everywhere would grant that.



Xenomai-core mailing list



Xenomai-core mailing list

Reply via email to