On Sat, 2011-07-16 at 10:13 +0200, Jan Kiszka wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2011-07-15 15:10, Jan Kiszka wrote: > > But... right now it looks like we found our primary regression: > > "nucleus/shadow: shorten the uninterruptible path to secondary mode". > > It opens a short windows during relax where the migrated task may be > > active under both schedulers. We are currently evaluating a revert > > (looks good so far), and I need to work out my theory in more > > details. > > Looks like this commit just made a long-standing flaw in Xenomai's > interrupt handling more visible: We reschedule over the interrupt stack > in the Xenomai interrupt handler tails, at least on x86-64. Not sure if > other archs have interrupt stacks, the point is Xenomai's design wrongly > assumes there are no such things.
Fortunately, no, this is not a design issue, no such assumption was ever made, but the Xenomai core expects this to be handled on a per-arch basis with the interrupt pipeline. As you pointed out, there is no way to handle this via some generic Xenomai-only support. ppc64 now has separate interrupt stacks, which is why I disabled IRQSTACKS which became the builtin default at some point. Blackfin goes through a Xenomai-defined irq tail handler as well, because it may not reschedule over nested interrupt stacks. Fact is that such pending problem with x86_64 was overlooked since day #1 by /me. > We were lucky so far that the values > saved on this shared stack were apparently "compatible", means we were > overwriting them with identical or harmless values. But that's no longer > true when interrupts are hitting us in the xnpod_suspend_thread path of > a relaxing shadow. > Makes sense. It would be better to find a solution that does not make the relax path uninterruptible again for a significant amount of time. On low end platforms we support (i.e. non-x86* mainly), this causes obvious latency spots. > Likely the only possible fix is establishing a reschedule hook for > Xenomai in the interrupt exit path after the original stack is restored > - - just like Linux works. Requires changes to both ipipe and Xenomai > unfortunately. __ipipe_run_irqtail() is in the I-pipe core for such purpose. If instantiated properly for x86_64, and paired with xnarch_escalate() for that arch as well, it could be an option for running the rescheduling procedure when safe. > > Jan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4hSDsACgkQitSsb3rl5xSmOACfbZfcNKyO9YDvPE+R5H75d0ky > DX0An32BrZW+lpEnxnLLCHSQ5r8itnE9 > =n6u8 > -----END PGP SIGNATURE----- -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
