On Thu, Dec 11, 2014 at 10:29:58AM +0000, Stoidner, Christoph wrote:
> >> >> RT drivers are also not installed on our system.
> >> >
> >> > Maybe I look wrong at nucleus/shadow.c, but I see only two reasons
> >> > for for xnshadow_relax being called for a secondary mode syscall:
> >> >
> >> > - a call requiring primary mode was made and the switchback flag is
> >> > set (which itself can have two reasons, either the fact that the
> >> > syscall uses it, the only one being currently rt_timer_set_mode, or
> >> > the fact that the caller runs with the SCHED_OTHER policy and does
> >> > not hold a mutex)
> >> >
> >> > - a call with the adaptive flag was made, handled in primary mode,
> >> > but returned -ENOSYS, which means the call needs to be retried in
> >> > secondary mode.
> >> >
> >>
> >> You are right. We have implemented some syscalls the require primary mode
> >> (since they could block) but should switch back to secondary. These
> >> syscalls are using attributes
> >>
> >> __xn_exec_primary | __xn_exec_switchback
> >
> > Well then the tasks blocked with a stack trace like what you showed
> > are blocked when coming back from such syscalls. Does this happen
> > often, or are these syscall seldom used?
>
> In this application the switchback syscalls are used rather often.
Two things to note:
- mode switches do not go without some overhead, it is almost never
a good idea to force the switchback, since the nucleus will switch
the target thread to secondary mode when needed anyway, all that you
risk is to introduce useless mode switches, so, if you do it, you
must have a good reason for it;
- there is a risk of overflowing the nucleus queue for relax
requests, you will see a message in the kernel logs when this
happens if you enable debugging of the nucleus
(CONFIG_XENO_OPT_DEBUG_NUCLEUS).
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
