On Thu, Dec 11, 2014 at 11:17:42AM +0000, Stoidner, Christoph wrote:
> >>
> >> 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;
>
> Yes I know. However we need to assure that the task switches back
> to secondary domain after using skin's call, since otherwise it
> would affect other linux tasks which actual have a higher
> linux-priority. In general we try to simulate something like
> "priority coupling" since this is marked as deprecated.
I understand, I guess this is the reason why xenomai-3 introduced
the XNWEAK scheduling class (which does the same thing by the way,
automatically switches back to secondary mode). I am not sure this
can compare to priority coupling though, since priority coupling
does the reverse: a task running in secondary mode may prevent other
tasks running in primary mode from running.
>
> >- 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).
>
> I have enabled CONFIG_XENO_OPT_DEBUG_NUCLEUS now but I do not see
> any according message.
Ok, maybe we have some hope with the tracer though. What should
trigger a trace is the fact that a relax request has been sent, but
that the next linux scheduling point does not wake up the said task.
This is all debug code, so it does not need to be clean. You can
define a per-cpu variable (if running on SMP systems, otherwise a
global variable will do) with the last request posted. And when a
linux scheduling happens, test that the newly scheduled task is the
task that was passed to the relax, if that is not the case, trigger
a trace freeze. The point where the nucleus is informed of a Linux
task switch is do_schedule_event(). The trick is that if you have
some tasks with a higher priority than the relaxed task, it is
normal that the relaxed task is not scheduled immediately, so if you
want the condition to hold, you need to run the xenomai tasks which
relax with the highest priority. Also, obviously, after the test,
the pointer should be reset to NULL, because there are several task
queued, and with a global variable you have no way of knowing which
is next.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
