[Xenomai] [PATCH] copperplate/mercury: introduce weak function to get OS max thread priority

Ronny Meeus ronny.meeus at gmail.com
Sun Dec 4 16:24:09 CET 2016

On Sun, Dec 4, 2016 at 11:26 AM, Philippe Gerum <rpm at xenomai.org> wrote:
> On 12/03/2016 09:39 PM, Ronny Meeus wrote:
>> On Sat, Dec 3, 2016 at 6:18 PM, Philippe Gerum <rpm at xenomai.org> wrote:
>>> On 11/30/2016 08:30 AM, Ronny Meeus wrote:
>>>> This patch introduces a weak function in the mercury copperplate code
>>>> that allows to put an upper limit on the priority used by the created thread
>>>> objects.
>>>> Before this patch the complete OS scheduler's FIFO range was used and it was
>>>> not possible to restrict it. Restricting it can be useful in case other
>>>> activities (typically platform related things) need to get a higher priority
>>>> than the application threads.
>>>> The example below shows what needs to be implemented in the application to
>>>> restrict the range.
>>> This looks weird. Any reason not to fix up the priority of your
>>> application threads?
>> Philippe,
>> this is not only about the application threads. We also need to lower
>> the priorities
>> used by the copperplate for the timer-thread and the task-lock priority.
>> The reason for this is that we need to run certain Linux kernel
>> threads at a higher
>> priority than any of the application threads, including Xenomai.
> That means that your system is running in some sort of sandboxed non-rt
> environment that may be subject to priority throttling by other parts of
> the system even for critical events, which is an interesting concept,
> but makes the Xenomai system inherently non-rt in this case. Such
> approach is not transposable to the Cobalt core running natively on the
> hw, and that is another issue in my eyes.


our use-case is a system that is ported from a native pSOS system so we
are actually after the pSOS interface. The RT aspect is less important for
us since we only have a 'soft' real-time systems, e.g. no strict deadlines.

We also had issues in the past that Linux RCU handling caused kernel
issues and we had to enable the CONFIG_RCU_BOOST option. To be on
the safe side, we configured the RCU_BOOST priority to be higher than
the prios used by the application, including the Xenomai threads.
For this to work we needed to create some "gap" between the MAX prio
supported by the scheduler and the max prio used by the apps.

Note that the critical events in our case are not handled by the Xenomai
applications, but by the Linux kernel event handlers (running in kernel

> I don't like the idea at all, but I will think of it anyway, to figure
> out whether this is compatible with some basic assumptions in Mercury.
> Bottom line is that adding yet another weak routine to get this is not
> the way to go, that would prevent multiple tuning points to co-exist
> into a single executable. At the very least, that would have to be a
> copperplate tunable.

I will provide a patch later that uses a tunable to configure this.
The weak implementation was inspired by the prio mapping function
that exists for the pSOS skin ...

> On a general note, let's reserve weak bindings for alternate versions of
> internal code or data, not part of the user interface.
> --
> Philippe.

More information about the Xenomai mailing list