Re: [Xenomai-help] New scheduler class

[Andreas Glatz <andreasglatz@domain.hid>]

On Thu, Apr 15, 2010 at 09:15:58AM -0400, Gilles Chanteperdrix wrote:
> Andreas Glatz wrote:
> > On Thu, Apr 15, 2010 at 08:40:00AM -0400, Gilles Chanteperdrix wrote:
> >> Andreas Glatz wrote:
> >>> Hi,
> >>>
> >>> On Thu, Apr 15, 2010 at 06:46:58AM -0400, Philippe Gerum wrote:
> >>>> On Wed, 2010-04-14 at 20:19 -0400, Andreas Glatz wrote:
> >>>>
> >>>>> One thing I've noticed though, and this is not related to the patch (I verified it on a
> >>>>> vanilla Xenomai system): Consider the example I included. It prints average cycle times
> >>>>> and the cycle time variance of the high priority task ("T2"). I noticed a big difference
> >>>>> in the cycle time variance when switching the first task ("T1") to secondary mode with
> >>>>> rt_task_set_mode() and setting the scheduler policy to either SCHED_FIFO, SCHED_IDLE or
> >>>>> SCHED_NORMAL. I'm assuming someone asked this before and I didn't pay attention :)
> >>>>> Can someone give me a short explanation or point me somewhere to get an explanation for
> >>>>> this behaviour? I didn't expect such a difference in variance:
> >>>>>
> >>>> Moving back to secondary mode is nothing more than triggering the
> >>>> rescheduling procedure linux-wise, so the time credit for
> >>>> SCHED_OTHER/IDLE tasks decay as usual during your work loop, preemption
> >>>> by high priority task is more likely and so on. This variance is just
> >>>> the sign that those tasks cannot ask for more than what their scheduling
> >>>> policy grants.
> >>>>
> >>> I think, I didn't express myself clearly enough. I was more puzzled about 
> >>> the variance of the pure RT task (task w/o any secondary mode switches).
> >>> So it seems that changing the scheduling policy of the "relaxed" task has
> >>> an influence on the variance of the pure RT task. So the RT task seems
> >>> to wait for the "relaxed" task. But where exacly does it wait for it? Mmmmm...
> >> When waiting for the mutex?
> >>
> > 
> > Ok. Maybe it's as ovvious as that. But I'm not quite there yet. Let me explain:
> > I know that the "relaxed" task ("T1") is in primary mode between rt_mutex_aquire()
> > and rt_mutex_release(). In other words when the pure RT task ("T2") starts waiting
> > on the mutex, "T1" should be primary mode and not be affected by the Linux 
> > scheduling policy. After "T1" releases the mutex it switches back to secondary mode.
> > So I would expect the variance to be constant. 
> 
> Right. Maybe the problem is that the first call made by a thread to
> rt_printf causes a switch to secondary mode (auto mode, means that the
> first call to rt_printf calls malloc). You can confirm that by arming
> the T_WARNSW bit.
>

Ok. You where right, too. The reason for the high variance (compared to the case
where both tasks always run in primary mode) comes from the fact that the pure 
RT task ("T2") starts blocking on rt_mutex_aquire() which in term boosts the 
priority of the "relaxed" task ("T1") running in primary mode (since it is between
rt_mutex_aquire/rt_mutex_release). 

At a first glance this made no sense to me since I thought that there shouldn't 
be any difference between the case where both tasks always run in primary mode 
and the case where "T1" switches to secondary mode only outside of 
rt_mutex_aquire/rt_mutex_release.

Now I found the reason: If I pass the flag T_PRIOFF to "T1" (the task which 
occasionally switches to secondary mode) I get the same variances for both cases
which I described in the previous paragraph. So the reason is clear: T2 not only
boosts the RT priority but also the Linux priority. Apparently, boosting the
Linux priority takes much longer and depends on the scheduling policy.

Is this a desired behaviour?

Andreas