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 <[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.

What do you call the "error case"?

> 
-- 
Philippe.



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

Reply via email to