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?

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

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to