Re: [Xenomai-core] Re: [patch, RFC] detect unhandled interrupts

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

Philippe Gerum wrote:
> On Wed, 2006-08-30 at 22:55 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2006-08-30 at 20:50 +0200, Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>
>>>>> On Wed, 2006-08-30 at 15:29 +0200, Jan Kiszka wrote:
>>>>>   
>>>>>> Dmitry Adamushko wrote:
>>>>>>     
>>>>>>> On 29/08/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>>>>>       
>>>>>>>> Dmitry Adamushko wrote:
>>>>>>>>
>>>>>>>> I think the additional costs of maintaining an error counter are almost
>>>>>>>> negligible. The test is in the unlikely path, and the first condition
>>>>>>>> already keeps us away from touching the counter.
>>>>>>>>         
>>>>>>> But it's updated (unhandled = 0) any time the ISR(s) report something
>>>>>>> different from XN_ISR_NONE.  Hence, it's at the beginning of the xnintr_t
>>>>>>> structure, hopefully, at the same cache line with other highly-used members
>>>>>>> (i.e. isr, cookie and hits).
>>>>>>>       
>>>>>> Mmh, considering this and also the existing code I wonder if we could
>>>>>> optimise this a bit. I'm only looking at xnintr_irq_handler now (sharing
>>>>>> is slow anyway): currently the intr object is touched both before
>>>>>> (naturally...) and after the call to the ISR handler. Maybe we can push
>>>>>> all accesses before the handler for the fast path. E.g.:
>>>>>>
>>>>>> int unhandled = intr->unhandled;
>>>>>>
>>>>>> intr->unhandled = 0;
>>>>>> ++intr->hits;
>>>>>> s = intr->isr(...);
>>>>>>
>>>>>> if (s == XN_ISR_NONE) {
>>>>>> 	intr->unhandled = ++unhandled;
>>>>>> 	if (unhandled == XNINTR_MAX_UNHANDLED)
>>>>>> 		ALARM!
>>>>>> }
>>>>>>
>>>>>>     
>>>>> Without speculating whether this could actually reduce cache misses or
>>>>> not when the branch is taken, the main issue I see here is that we would
>>>>> optimize the error case, at the expense of an additional memory fetching
>>>> No, it's the common path. Otherwise, I would have stopped already. I don't
>>>> expect further memory access because the head of intr should be cached
>>>> already.
>>>>
>>> Sorry, my brain cells must be glued together, but then, I just don't get
>>> what your patch actually optimizes :o}
>> Cache misses when accessing intr AFTER the ISR has finished (not on
>> latest Pentium with 4 MB caches...) for the non-error case.
> 
> What do you call the "error case"?
> 

XN_ISR_NONE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]