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

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

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
- fix upstream glibc - non-trivial, as history shows, but long overdue

Jan

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