[Xenomai-help] primary mode versus secondary mode

[Xenomai-help] primary mode versus secondary mode

[Paul Ianna]

Hi All,

I have read (at least some of) the Xenomai docs and am a little
unclear on the real distinction between primary and secondary mode.

I have seen in the native API that I can receive a signal if a task
has "migrated to the Linux domain".

Does secondary mode mean that I am no longer a real-time task?

How do I avoid dropping from primary mode to secondary mode?

Thanks in advance,
Paul Ianna

Re: [Xenomai-help] primary mode versus secondary mode

[Philippe Gerum]

On Mon, 2006-08-21 at 16:21 -0400, Paul Ianna wrote:
> Hi All,
> 
> I have read (at least some of) the Xenomai docs and am a little
> unclear on the real distinction between primary and secondary mode.
> 
> I have seen in the native API that I can receive a signal if a task
> has "migrated to the Linux domain".
> 
> Does secondary mode mean that I am no longer a real-time task?
> 

Not exactely; it means that your real-time task is entering an execution
mode controlled by the regular Linux scheduler, therefore leaving the
Xenomai one. This means that predictability regarding latencies is
limited by what the vanilla Linux kernel can achieve, in terms of
determinism (i.e. not much by our standards). Your task will switch back
to strict real-time mode automatically when issuing a Xenomai syscall
that requires it (e.g. all blocking Xenomai syscall do).

> How do I avoid dropping from primary mode to secondary mode?
> 

- Avoid using plain Linux signals to send asynchronous notifications to
your RT tasks
- Avoid calling any code that could directly or indirectly issue a
regular Linux syscall (e.g. anything from the glibc that might call back
the kernel to perform the operation, like acquiring/releasing a
contended mutex, extending the data segment [malloc -> brk]  etc.)

Aside of this, you can be informed of any mode transition from primary
to secondary mode using the rt_task_setmode() call, arming the T_WARNSW
bit for the current task. This will send your task a SIGXCPU signal each
time it crosses the boundary. Have a look at
ksrc/skins/native/snippets/sigxcpu.c, it's a simple illustration of this
service.

Also have a look at /proc/xenomai/stats when your application runs, the
MSW field (i.e. Mode SWitches) counts the number of transitions for each
Xenomai thread. This value should not increase over time, at least for
latency critical threads.

> Thanks in advance,
> Paul Ianna
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] primary mode versus secondary mode

[Jan Kiszka]

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

Paul Ianna wrote:
> Hi All,
> 
> I have read (at least some of) the Xenomai docs and am a little
> unclear on the real distinction between primary and secondary mode.
> 
> I have seen in the native API that I can receive a signal if a task
> has "migrated to the Linux domain".
> 
> Does secondary mode mean that I am no longer a real-time task?

As long as your task is in this mode, Linux can do with it again what it
wants to. This phase ends once you call a Xenomai service that requires
primary mode or you enforce a mode switch (rt_task_set_mode, but for
most applications designs not required).

> 
> How do I avoid dropping from primary mode to secondary mode?

Avoid executing Linux system services (file I/O, networking, printf,
etc.) in critical code paths, avoid sending Linux signal to the task.
But if you write a hard real-time application, you are likely doing a
careful review of what your time-critical code finally does anyway ;).
If not (don't tell it anyone...), the SIGXCPU signal raised on mode
switches can guide you finding fishy parts.

Jan


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

Re: [Xenomai-help] primary mode versus secondary mode

[Paul Ianna]

On 8/21/06, Philippe Gerum <rpm@xenomai.org> wrote:
> Also have a look at /proc/xenomai/stats when your application runs, the
> MSW field (i.e. Mode SWitches) counts the number of transitions for each
> Xenomai thread. This value should not increase over time, at least for
> latency critical threads.

Thanks Philippe, very useful.

Could you also explain the CSW, PF, and STAT fields?

Thanks,
Paul

Re: [Xenomai-help] primary mode versus secondary mode

[Philippe Gerum]

On Wed, 2006-08-23 at 16:00 -0400, Paul Ianna wrote:
> On 8/21/06, Philippe Gerum <rpm@xenomai.org> wrote:
> > Also have a look at /proc/xenomai/stats when your application runs, the
> > MSW field (i.e. Mode SWitches) counts the number of transitions for each
> > Xenomai thread. This value should not increase over time, at least for
> > latency critical threads.
> 
> Thanks Philippe, very useful.
> 
> Could you also explain the CSW, PF, and STAT fields?

CSW: # of context-switches (seen by the Xenomai scheduler, not the Linux
one)
PF: # of page faults (should stop increasing as soon as mlockall is in
effect)
STAT: a bitfield describing the internal state of the thread. Bit values
are defined in include/nucleus/thread.h (See status and mode bits). The
STAT field from /proc/xenomai/sched gives a 1-letter-per-bit symbolic
translation of a the most significant subset of those bits (from a user
POV, that is). See "Status symbols" in the same source file. 

> 
> Thanks,
> Paul
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.