[Xenomai-core] Question about shadow migration

[Xenomai-core] Question about shadow migration

[Jan Kiszka]

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

Hi,

I'm currently trying to confirm my understanding of what precisely
happens during a switch-back of a shadow thread from primary to
secondary mode. I guess the thrilling things happen in xnshadow_relax().
The shadow enters in primary and leaves in secondary.

The question for me is now if I got these details right: first a
migration request is issued [1] but not immediately executed, then the
priority of the root thread (Linux) is lifted to the one of the shadow
thread [2], 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?), 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?

Thanks,
Jan


[1] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L540
[2] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L542
[3] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L543
[4] www.rts.uni-hannover.de/xenomai/lxr/source/nucleus/shadow.c#L254

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

Re: [Xenomai-core] Question about shadow migration

[Dmitry Adamushko]

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



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)

>
> Thanks,
> Jan
>
>

---
Best regards,
Dmitry

[-- Attachment #2: Type: text/html, Size: 3883 bytes --]

Re: [Xenomai-core] Question about shadow migration

[Jan Kiszka]

[-- 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 --]