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.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
