On 2011-06-18 16:01, Gilles Chanteperdrix wrote: > On 06/18/2011 03:47 PM, Jan Kiszka wrote: >> On 2011-06-18 15:40, Gilles Chanteperdrix wrote: >>> On 06/18/2011 03:16 PM, Jan Kiszka wrote: >>>> On 2011-06-18 15:12, Gilles Chanteperdrix wrote: >>>>> On 06/18/2011 03:07 PM, Jan Kiszka wrote: >>>>>> On 2011-06-18 14:56, Gilles Chanteperdrix wrote: >>>>>>> >>>>>>> Maybe in the irq handlers, we should skip the XNHTICK replay, when >>>>>>> current_domain is root_domain. >>>>>>> >>>>>> >>>>>> That would be against the purpose of the XNTICK replay (it only targets >>>>>> that particular case). And it would still leave us with broken ipipe due >>>>>> to enabled IRQs on return from the Xenomai handlers. >>>>> >>>>> What I mean is that xnintr_clock_handler, we should skip the XNHTICK >>>>> replay when the current domain upon return from xnpod_schedule is not >>>>> root. From what I understand, this case only happens when xnpod_schedule >>>>> migrated the thread, and in that case, the tick will have been forwarded >>>>> during xnpod_schedule anyway. >>>> >>>> In the problematic case, ie. when the XNHTICK replay uses an invalid >>>> sched, the current domain is root. It must be root because only then the >>>> context could have been migrated to a different CPU by Linux. So this >>>> does not help to avoid having to reload sched. >>> >>> I mean replace: >>> if (testbits(sched->lflags, XNHTICK) && >>> xnthread_test_state(sched->curr, XNROOT)) >>> xnintr_host_tick(sched); >>> >>> with >>> if (!xnarch_root_domain_p() && >>> testbits(sched->lflags, XNHTICK) && >>> xnthread_test_state(sched->curr, XNROOT)) >>> xnintr_host_tick(sched); >>> >> >> That breaks Linux timer ticks: If we are only running the root thread, >> where should the pending tick be replayed? It is always deferred, even >> over the root domain. And __xnpod_schedule, which could replay it as >> well, is only entered if there is rescheduling required. > > I may be wrong, but it is my understanding that Adeos switches domain > before executing interrupt handlers, so that the current Adeos domain > when running xnintr_clock_handler is always Xenomai, except at this > point if we have migrated. For instance, see the following trace : > > | +func -9296 __ipipe_grab_localtimer+0x10 (__irq_usr+0x3c) > | +func -9295 __ipipe_grab_irq+0x10 > (__ipipe_grab_localtimer+0x20) > | +func -9295 __ipipe_handle_irq+0x10 > (__ipipe_grab_irq+0x88) > | +func -9295 __ipipe_ack_localtimer+0x10 > (__ipipe_handle_irq+0xc8) > | +func -9294 __ipipe_dispatch_wired+0x10 > (__ipipe_handle_irq+0xd4) > | +func -9293 __ipipe_dispatch_wired_nocheck+0x14 > (__ipipe_dispatch_wired+0x50) > | # func -9293 xnintr_clock_handler+0x14 > (__ipipe_dispatch_wired_nocheck+0x88) > > where we clearly see that the current domain is xenomai when executing > xntintr_clock_handler.
Yeah, that's true. > > Anyway, reading ipipe_current_domain is probably as expensive as > reading xnpod_current_sched(). > And it would extend the common code path by another test. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
