[Xenomai-help] Fast-sync and auto-relaxed priority 0 threads

[Xenomai-help] Fast-sync and auto-relaxed priority 0 threads

[Henri Roosen]

Hi,

We are using the auto-relax patches on top of the latest Xenomai 2.5.6
release. This means our priority 0 task is in secondary domain most of
the time.

We've seen a lot of domain switching and gatekeeper activity when this
task is acquiring a mutex which is not locked. Of course an
auto-relaxed prio 0 thread will do domain switching more often, but in
this case because we have fast sync enabled I would expect it doesn't
have to make a kernel call thus no switching..

Looking into the code I've found that at rt_mutex_acquire_inner there
is explicitly a check for secondary domain. This must have been done
while xnsynch_fast_acquire can only be called from primary domain. Is
that the case?? In the implementation behind xnsynch_fast_acquire I
cannot find a reason why it cannot be called from secondary domain.
Can anyone comment on this?

It would save a lot of overhead for our priority 0 task if we could
have fast sync in secondary mode. All suggestions are welcome!

Thanks,
Henri.

Xenomai: 2.5.6 + auto-relax patches.
Linux-kernel: 2.6.32.15
Platform: x86

Re: [Xenomai-help] Fast-sync and auto-relaxed priority 0 threads

[Gilles Chanteperdrix]

On 05/12/2011 02:07 PM, Henri Roosen wrote:
> Hi,
> 
> We are using the auto-relax patches on top of the latest Xenomai 2.5.6
> release. This means our priority 0 task is in secondary domain most of
> the time.
> 
> We've seen a lot of domain switching and gatekeeper activity when this
> task is acquiring a mutex which is not locked. Of course an
> auto-relaxed prio 0 thread will do domain switching more often, but in
> this case because we have fast sync enabled I would expect it doesn't
> have to make a kernel call thus no switching..
> 
> Looking into the code I've found that at rt_mutex_acquire_inner there
> is explicitly a check for secondary domain. This must have been done
> while xnsynch_fast_acquire can only be called from primary domain. Is
> that the case?? In the implementation behind xnsynch_fast_acquire I
> cannot find a reason why it cannot be called from secondary domain.
> Can anyone comment on this?
> 
> It would save a lot of overhead for our priority 0 task if we could
> have fast sync in secondary mode. All suggestions are welcome!

Yes, the automatic switch to primary mode is made on purpose. It is a
kind of priority inheritance, when a thread holds a mutex, this mutex
may be shared with a primary mode only thread, so, we do not want the
linux scheduler to take the decision of preempting this task, and create
a priority inversion.

It is hard to do this differently: if a real-time thread arrives and try
and take the mutex while the priority 0 thread is preempted by Linux
scheduler, there is not much we can do without hacking savagely the
Linux scheduler.

What we can do however, is do this only for threads with priority
inheritance.

-- 
					    Gilles.

Re: [Xenomai-help] Fast-sync and auto-relaxed priority 0 threads

[Henri Roosen]

On Thu, May 12, 2011 at 2:50 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 05/12/2011 02:07 PM, Henri Roosen wrote:
>> Hi,
>>
>> We are using the auto-relax patches on top of the latest Xenomai 2.5.6
>> release. This means our priority 0 task is in secondary domain most of
>> the time.
>>
>> We've seen a lot of domain switching and gatekeeper activity when this
>> task is acquiring a mutex which is not locked. Of course an
>> auto-relaxed prio 0 thread will do domain switching more often, but in
>> this case because we have fast sync enabled I would expect it doesn't
>> have to make a kernel call thus no switching..
>>
>> Looking into the code I've found that at rt_mutex_acquire_inner there
>> is explicitly a check for secondary domain. This must have been done
>> while xnsynch_fast_acquire can only be called from primary domain. Is
>> that the case?? In the implementation behind xnsynch_fast_acquire I
>> cannot find a reason why it cannot be called from secondary domain.
>> Can anyone comment on this?
>>
>> It would save a lot of overhead for our priority 0 task if we could
>> have fast sync in secondary mode. All suggestions are welcome!
>
> Yes, the automatic switch to primary mode is made on purpose. It is a
> kind of priority inheritance, when a thread holds a mutex, this mutex
> may be shared with a primary mode only thread, so, we do not want the
> linux scheduler to take the decision of preempting this task, and create
> a priority inversion.
>
> It is hard to do this differently: if a real-time thread arrives and try
> and take the mutex while the priority 0 thread is preempted by Linux
> scheduler, there is not much we can do without hacking savagely the
> Linux scheduler.
>

I understand. Thanks Gilles for the explanation!

> What we can do however, is do this only for threads with priority
> inheritance.
>
> --
>                                            Gilles.
>