I compiled our application on the Xenomai target, and started to run it. All
activities are explicitely set as ORO_SCHED_OTHER, which -- as far as I
understood -- ensures that the task is in Xenomai's secondary domain (i.e.
non-RT).
The issue is that Xenomai reports that the task has a LOT of mode switches
from primary to secondary. At least, that is what /proc/xenomai/stat is
reporting.
The task is using FileDescriptorDrivenActivity, and I tried to add
rt_task_set_mode(T_PRIMARY, 0, 0)
directly in FileDecriptorActivity::loop(), but that did not change the
behaviour.
Then, I added T_WARNSW and I did get the SIGXCPU signal whenever the IO was
accessed (as I expected since the IO driver is not realtime).
I'm lost. Why would the task go into primary mode while it is explicitely set
to secondary ? I'm probably missing something there ...
Sylvain
Newbie question on Xenomai and ORO_SCHED_OTHER
On Fri, Jul 17, 2009 at 12:45, Sylvain Joyeux<sylvain [dot] joyeux [..] ...> wrote:
> I compiled our application on the Xenomai target, and started to run it. All
> activities are explicitely set as ORO_SCHED_OTHER, which -- as far as I
> understood -- ensures that the task is in Xenomai's secondary domain (i.e.
> non-RT).
But we can't. Xenomai always switches us back to primary, even if we
clear the T_PRIMARY flag (which we do). I've been looking at this
recently, and the only possible solution I see is to run Xenomai
threads in SCHED_OTHER instead of SCHED_FIFO, and hoping that Xenomai
interpretes this as 'run in the secondary domain' (I'm betting it
does). In RTT 1.8.x, all Xenomai threads run in SCHED_FIFO. We should
probably change xenomai/fosi_internal to replace each occurence of
rt_task_set_mode with a call to pthread_set_scheduler and changing
between SCHED_OTHER and SCHED_FIFO. This would be a blunt copy/paste
from gnulinux/fosi_internal.cpp.
Peter
Newbie question on Xenomai and ORO_SCHED_OTHER
On Friday 17 July 2009 14:21:51 Peter Soetens wrote:
> On Fri, Jul 17, 2009 at 12:45, Sylvain Joyeux<sylvain [dot] joyeux [..] ...> wrote:
> > I compiled our application on the Xenomai target, and started to run it.
> > All activities are explicitely set as ORO_SCHED_OTHER, which -- as far as
> > I understood -- ensures that the task is in Xenomai's secondary domain
> > (i.e. non-RT).
>
> But we can't. Xenomai always switches us back to primary, even if we
> clear the T_PRIMARY flag (which we do). I've been looking at this
> recently, and the only possible solution I see is to run Xenomai
> threads in SCHED_OTHER instead of SCHED_FIFO, and hoping that Xenomai
> interpretes this as 'run in the secondary domain' (I'm betting it
> does). In RTT 1.8.x, all Xenomai threads run in SCHED_FIFO. We should
> probably change xenomai/fosi_internal to replace each occurence of
> rt_task_set_mode with a call to pthread_set_scheduler and changing
> between SCHED_OTHER and SCHED_FIFO. This would be a blunt copy/paste
> from gnulinux/fosi_internal.cpp.
Looking at the mailing lists, it appears that Xenomai switches to primary mode
each time a Xenomai syscall is called. My bet is that read() and write() are
wrapped -- even though we use native mode and not posix skin, the xenomai lib
probably wraps it -- and since my CAN driver is not RT (yet) I get switched
back to secondary during the syscall.
I'll try to check your proposed fix as soon as I can. In the meantime, I'll
simply have to use SCHED_FIFO in the gnulinux target.
Newbie question on Xenomai and ORO_SCHED_OTHER
On Mon, Jul 20, 2009 at 10:25:21AM +0200, Sylvain Joyeux wrote:
> On Friday 17 July 2009 14:21:51 Peter Soetens wrote:
> > On Fri, Jul 17, 2009 at 12:45, Sylvain Joyeux<sylvain [dot] joyeux [..] ...> wrote:
> > > I compiled our application on the Xenomai target, and started to run it.
> > > All activities are explicitely set as ORO_SCHED_OTHER, which -- as far as
> > > I understood -- ensures that the task is in Xenomai's secondary domain
> > > (i.e. non-RT).
> >
> > But we can't. Xenomai always switches us back to primary, even if we
> > clear the T_PRIMARY flag (which we do). I've been looking at this
> > recently, and the only possible solution I see is to run Xenomai
> > threads in SCHED_OTHER instead of SCHED_FIFO, and hoping that Xenomai
> > interpretes this as 'run in the secondary domain' (I'm betting it
> > does). In RTT 1.8.x, all Xenomai threads run in SCHED_FIFO. We should
> > probably change xenomai/fosi_internal to replace each occurence of
> > rt_task_set_mode with a call to pthread_set_scheduler and changing
> > between SCHED_OTHER and SCHED_FIFO. This would be a blunt copy/paste
> > from gnulinux/fosi_internal.cpp.
>
> Looking at the mailing lists, it appears that Xenomai switches to primary mode
> each time a Xenomai syscall is called. My bet is that read() and write() are
> wrapped -- even though we use native mode and not posix skin, the xenomai lib
> probably wraps it -- and since my CAN driver is not RT (yet) I get switched
> back to secondary during the syscall.
If it's really only read/write you could try to force these syscalls
to the Linux ones by using the __real_write/__real_read variants and
see if you are switched less.
Markus