* Re: [Xenomai-help] primary mode versus secondary mode
2006-08-21 20:21 ` [Xenomai-help] primary mode versus secondary mode Paul Ianna
@ 2006-08-21 20:42 ` Philippe Gerum
2006-08-23 20:00 ` Paul Ianna
2006-08-21 20:44 ` Jan Kiszka
1 sibling, 1 reply; 5+ messages in thread
From: Philippe Gerum @ 2006-08-21 20:42 UTC (permalink / raw)
To: Paul Ianna; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-help] primary mode versus secondary mode
2006-08-21 20:21 ` [Xenomai-help] primary mode versus secondary mode Paul Ianna
2006-08-21 20:42 ` Philippe Gerum
@ 2006-08-21 20:44 ` Jan Kiszka
1 sibling, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2006-08-21 20:44 UTC (permalink / raw)
To: Paul Ianna; +Cc: xenomai
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread