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 

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

> Jan

Best regards,

Reply via email to