Re: [Xenomai] [xenomai-forge] timer-internal consume a lot of cpu

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2014-12-18 16:49, Ronny Meeus wrote:
> On Thu, Dec 18, 2014 at 4:35 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2014-12-18 16:30, Gilles Chanteperdrix wrote:
>>> On Thu, Dec 18, 2014 at 04:25:40PM +0100, Ronny Meeus wrote:
>>>> On Thu, Dec 18, 2014 at 4:04 PM, Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>> On Thu, Dec 18, 2014 at 03:58:52PM +0100, Jan Kiszka wrote:
>>>>>> On 2014-12-18 15:12, Gilles Chanteperdrix wrote:
>>>>>>> Otherwise, have you tried some alternate libc, such as musl:
>>>>>>> http://www.musl-libc.org/
>>>>>>>
>>>>>>> The following blog:
>>>>>>> http://ewontfix.com/
>>>>>>>
>>>>>>> Seems to show that the musl maintainers try and report glibc bugs
>>>>>>> and avoid them in their implementation.
>>>>>>>
>>>>>>> I have not tried xenomai with musl at all, so, maybe it does not
>>>>>>> even compile. But maybe just compiling a testcase for the condvar
>>>>>>> issue with that libc would help know if it has the same issue or
>>>>>>> not.
>>>>>>
>>>>>> Well, like with many of those "light-weight" re-implementations, the are
>>>>>> "small" issues with bits required for real-time:
>>>>>>
>>>>>> http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_mutexattr_setprotocol.c
>>>>>
>>>>> On the other hand, no implementation with a clear ENOTSUPP is better
>>>>> than a partial and buggy implementation that can not be trusted anyway.
>>>>>
>>>>> --
>>>>>                                             Gilles.
>>>>
>>>> Gilles I agree.
>>>>
>>>> In the meantime I tried it already.
>>>>
>>>> This is indeed the trace I get when running my test application with musl.
>>>> # ./cond_test_arm
>>>> # hread_mutexattr_setprotocol: Not supported
>>>>
>>>> Cobalt is not an option for us either since in that case all Linux
>>>> applications will run in low-priority. Next to that we also have a
>>>> huge priority inversion each time a Linux system call is done.
>>>>
>>>> Do we have other options to fix forge?
>>>
>>> Well, three options have been proposed if I followed this thread
>>> correctly:
>>> - stop using priority inheritance for these internal mutexes, at the
>>> risk of creating priority inversions
>>> - switch to priority ceiling (but what will be the ceiling? 99?)
>>
>> Likely - part of the reason why that is no general solution.
>>
>>> - use cobalt.
>>
>> - use a patched glibc
> 
> I tried to apply the patch on glibc 2.20 but it looks like the issue is still
> present.

You will need to extend to existing condvar users and tell glibc that
those vars will be used in combination with PI mutexes
(pthread_condattr_setprotocol_np).

> Even if it would be solved with the patch, we force all users
> of forge to work with a patched version of glibc and to go to 2.20.
> This might not always be easy.

Yes, that is unhandy.

> 
>> - fix upstream glibc - non-trivial, as history shows, but long overdue
> 
> Another option is to implement the priority boost in the copperplate lib.
> Before the signal is done, change the priority to an equal priority as
> the task signaling the conditional variable (in case the prio or the
> waiting task is lower).
> Once the thread is unblocked, restore the original priority (from the
> thread that receives the signal).

That implies you know the prios of the involved threads. Doesn't sound
like a generic solution either.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux