On 2011-07-16 11:56, Philippe Gerum wrote: > On Sat, 2011-07-16 at 11:15 +0200, Jan Kiszka wrote: >> On 2011-07-16 10:52, Philippe Gerum wrote: >>> On Sat, 2011-07-16 at 10:13 +0200, Jan Kiszka wrote: >>>> 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. >> >> And that's already the problem: If Linux uses interrupt stacks, relying >> on ipipe to disable this during Xenomai interrupt handler execution is >> at best a workaround. A fragile one unless you increase the pre-thread >> stack size by the size of the interrupt stack. Lacking support for a >> generic rescheduling hook became a problem by the time Linux introduced >> interrupt threads. > > Don't assume too much. What was done for ppc64 was not meant as a > general policy. Again, this is a per-arch decision.
Actually, it was the right decision, not only for ppc64: Reusing Linux interrupt stacks for Xenomai does not work. If we interrupt Linux while it is already running over the interrupt stack, the stack becomes taboo on that CPU. From that point on, no RT IRQ must run over the Linux interrupt stack as it would smash it. But then the question is why we should try to use the interrupt stacks for Xenomai at all. It's better to increase the task kernel stacks and disable interrupt stacks when ipipe is enabled. That's what I'm heading for with x86-64 now (THREAD_ORDER 2, no stack switching). What we may do is introducing per-domain interrupt stacks. But that's at best Xenomai 3 / I-pipe 3 stuff. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
