Dmitry Adamushko wrote:
> On Monday 31 October 2005 21:38, you wrote:
>>> [...]
>>> 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?
> In that case, the nucleus must keep track of all the irqs, i.e. some_struct 
> irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq[] may be removed here from 
> hal.
> But there is already the per-irq array in ipipe_domain struct. Having got [1] 
> and [2] merged, we would have this array as the only one and avoid the use of 
> rthal_realtime_irq[] at all. Although, the ipipe_domain would become a bit 
> more heavy :) Well, but [2] into [3] is leeeess intrusive on the other hand.

Due to the intrusiveness, I would vote for a [2]->[3] merge.

One issue remains in any case: the HAL currently maintains a /proc entry
for the registered IRQs. It reports if a handler is registered and the
IRQ hits per CPU. As I think this entry should also report the
registered driver names in the future, we have to hand the management
over to whatever part traces all registered handlers. Is this acceptable
from the layering point of view?


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to