Re: [Xenomai-help] Priority coupling broken?

[Philippe Gerum <rpm@xenomai.org>]

On Wed, 2011-03-30 at 09:30 +0200, Henri Roosen wrote:
> On Wed, Mar 30, 2011 at 6:58 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> > On Tue, 2011-03-29 at 21:29 +0200, Gilles Chanteperdrix wrote:
> >> Philippe Gerum wrote:
> >> > On Tue, 2011-03-29 at 21:19 +0200, Gilles Chanteperdrix wrote:
> >> >> Philippe Gerum wrote:
> >> >>> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
> >> >>>> Philippe Gerum wrote:
> >> >>>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
> >> >>>>>> at the same time. Priority coupling is enabled in the kernel.
> >> >>>>>>
> >> >>>>>> If one of them (unfortunately) makes a Linux system call, I see that
> >> >>>>>> first other lower and same priority Xenomai tasks are scheduled before
> >> >>>>>> the switched task is run in the Linux domain. As I understand,
> >> >>>>>> priority coupling should prevent this.
> >> >>>>>>
> >> >>>>>> To rule out a problem in the application, this is also tested with a
> >> >>>>>> simple application based on the rt_print example. In my opinion, with
> >> >>>>>> priority coupling enabled this should print:
> >> >>>>>> Wakeup! - I am - awake! - Me too!
> >> >>>>>> But I get:
> >> >>>>>> Wakeup! - I am - Me too! - awake!
> >> >>>>>> So task 2 gets run before task 3 completes in the Linux domain.
> >> >>>>>>
> >> >>>>>> Please find attached the test application and the .config file.
> >> >>>>> The fine print with priority coupling is that it stops immediately
> >> >>>>> whenever the thread blocks linux-wise; this is actually why, after all
> >> >>>>> this time debugging it, I'm pondering now whether I should keep this
> >> >>>>> behavior/feature in 3.x.
> >> >>>>>
> >> >>>>> Initially, this was aimed at enforcing the right scheduling sequence
> >> >>>>> with traditional RTOS APIs, specifically when it comes to create
> >> >>>>> threads, so that high priority children do run prior to low priority
> >> >>>>> parents (some legacy apps may expect this). But the fact is that this
> >> >>>>> behavior also carries a number of uncertainties, and having the thread
> >> >>>>> de-boosted when blocked by Linux is a serious one.
> >> >>>> Maybe each thread could have a bit telling whether or not it should run
> >> >>>> under priority coupling, this bit would be disabled at all times, except
> >> >>>> during the thread creation routines, and at other times if the user
> >> >>>> called xnpod_set_mode to enable it if he wants?
> >> >>>>
> >> >>> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
> >> >>> makes sense to provide priority coupling without any mean to actually
> >> >>> control the impact the regular kernel may have on it.
> >> >>>
> >> >> without the irq shield you mean :-)
> >> >>
> >> >
> >> > No, it is not related. The issue now is with the inability to determine
> >> > whether and when the kernel may cause the priority boost to drop without
> >> > the user knowing about it.
> >> >
> >> Maybe we could add a new SIGDEBUG reason ?
> >>
> >
> > SIGDEBUG is for detecting a misuse of some feature, the issue may be
> > that the feature could be a misuse of the scheduling system in itself.
> > This is what should be pondered before any other move.
> >
> > --
> > Philippe.
> >
> >
> >
> 
> Using a data array to track the switches and replace gettimeofday()
> with sched_yield() shows the same sequence of events. Actually the
> problem was shown in our main application that already uses a data
> array for trace data, The rt_print based app was just for simple
> reproducing the problem.
> 
> Our realtime thread should actually not do Linux system calls, neither
> should it cause exceptions, but unfortunately we don't have total
> control over that. So when it does make a system call we rely on
> priority coupling that the task completes before the lower priority
> realtime threads are scheduled. Our tracing tool shows this is not the
> case.
> 
> What can I do to help fixing the priority coupling?

As discussed earlier, it still remains to show whether linux blocks the
task for whatever reason when issuing the syscall. In such a case, there
is not much you could do, since you would simply face a limitation of
the prio coupling design, there is no fix for this one.

I would suggest to instrument rpi_switch(), to check whether the task is
de-boosted for that reason, to make sure we are not chasing wild gooses.

> 
> Thanks,
> Henri.

-- 
Philippe.