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 <[EMAIL PROTECTED]> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
