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.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
