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

This would mean changing a core Adeos prototype, though.

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.

I'd really prefer making one invasive change early in the process of addressing the issue than several kludges later to work around structural shortcomings, so no problem, go wild, I'm all ears.

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...


Best regards,

Xenomai-core mailing list



Xenomai-core mailing list

Reply via email to