Re: [Xenomai-core] Question about shadow migration

[Jan Kiszka <kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]

Dmitry Adamushko wrote:
> 
> xenomai-core-bounces@domain.hid 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)
> 

No, I actually got it :). I'm preparing a presentation about Xenomai,
and now I can even boast a bit more with details. ;)

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]