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