Re: [Xenomai-core] Question about shadow migration

[Dmitry Adamushko]

[EMAIL PROTECTED] wrote on 16.11.2005 09:09:07:

>
> The question for me is now if I got these details right: first a
> migration request is issued [1] but not immediately executed,

This request is about scheduling an APC for execution (which is lostage_apc in that case). The APC mechanism is implemented on top of the VIRQ mechanism so when Linux gets control back it has a pending VIRQ that will be executed at the first appropriate point. It's not immediately actually since the Linux domain could have been preempted last time at some point with the interrupts off.
The VIRQ handler, in turn, wakes up a desired process (i.e. puts it in the linux's runqueue) so it can be run again at the next preempteble point. Sure, there can be other runnable processes with higher prios.

> then the
> priority of the root thread (Linux) is lifted to the one of the shadow
> thread [2]

Yes, in order to prevent other rt activities with lower rt prios from preempting a soon-to-be-relaxed thread while it's going to be run in the secondary mode. So it's about keeping the sole priority scheme across domains (classical RTAI does the opposite to my knowledge).

>, and then the shadow thread is suspend with respect to the
> xenomai scheduler [3]. The last step should let the Linux kernel start
> over again, run to its next preemption point (and this is the region
> where non-deterministic delays may be injected with current kernels,
> isn't it?),

Yes, there are 2 points:

- a time between a moment when the Linux domain gets control back and the moment when VIRQ->APC->lostage_handler may be executed (*);

e.g. the Linux domain could have been preempted last time at some point with the interrupts off so we are dependent on the lenght of irq-off sections in the linux kernel.

- a time between (*) and the next preemption point when a newly awakenen task may get control back.

e.g. other asynch. activities have been previously scheduled in the linux domain (pending interrupts, bottom halves).

The IRQ shield (if used) protects only from the asynch. activities that may occur when a rt task is already executing in the linux domain, not from those that were scheduled for execution before the rt task has entered the linux domain.


> and switch over to lostage_handler() [4] to resume the Linux
> part of the shadow thread. After that the execution of the shadow, now
> in secondary mode, continues in xnshadow_relax() after [3]. Am I right?

Yes, Actually, another interesting point here is rthal_reenter_root().
It's about properly (re-)adjusting a priority of the linux thread if the shadow counterpart has changed its priority while running in the primary domain. The linux thread is executing with its old priority between L543 and L551. So it's a small priority-related flaw regarding the migration scheme. The reason is that it's not possible (likely it's possible with linux versions >= 2.6.13) to properly change the priority of the linux task on top of VIRQs (ISR handlers). Once we have discussed it with Philippe and there can be another solution though. But we decided to wait a bit until all the dust with scheduler-related changes in 2.6.x settles down.

Hopefully, I haven't misled you too much with my comments :o)

>
> Thanks,
> Jan
>
>

---
Best regards,
Dmitry