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

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

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

Dmitry Adamushko wrote:
> On 30/08/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>
>>
>> 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!
>> }
> 
> 
> so the idea is that we touch all intr members while they are hopefully in
> the same cache line (if it's 128 bits long) as the cache may be
> disturbed by
> ISR afterwards.
> 
> But OTOH, we do an additional write "int unhandled = intr->unhandled;"
> 
> (write-through cache) ---> put in cache + syncing with memory immediately
> 
> (write-back cache) ---> put in cache + delay syncing (but will it still
> happen?)
> 
> So while we avoid one possible read from the main memory into the cache
> when
> intr->unhandled and ->hits (ok, this one can be moved for sure) are called
> after ISR (and they are not in the cache), we introduce another one (at
> least for write-through it's 100%) that takes place before ISR and that's
> actually a "+" component to the IRQ latency.
> 
> or I can be wrong though.
> 

That also depends on what information the compiler keeps on the stack
and what in registers. On x86, sched of our xnintr_irq_handler remains
in some register while the ISR executes. The same may happen to
unhandled, but it's hard to predict. It's also the question what we want
to improve, ISR latencies or the final user latency (the latter includes
the post ISR part).

Ok, such stuff makes sense if we can say that for most cases (archs),
specifically low-end scenarios, there is some gain. Guess this would
need testing... :-/

Jan


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