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

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

On 2014-12-18 13:28, Ronny Meeus wrote:
> On Thu, Dec 18, 2014 at 10:04 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2014-12-18 09:00, Ronny Meeus wrote:
>>>>
>>>> A release of the glibc that fixes this issue. I must admit that I did
>>>> not track this problem lately. Jan likely knows better here.
>>>>
>>>
>>> Jan,
>>>
>>> what version glibc solves the priority inversion issue on conditional variables?
>>> I already tried the glibc 2.18 but the issue is still there.
>>
>> The bug is still not fixed, and discussion stalled again, see
>> https://sourceware.org/bugzilla/show_bug.cgi?id=11588
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RTC ITP SES-DE
>> Corporate Competence Center Embedded Linux
> 
> Philippe, Jan
> 
> as long as this issue is not fixed in glibc, it is not OK to use
> conditional variables
> in application space for real-time applications in my opinion.

...when combining them with PI mutexes, right. For real-time QEMU/KVM, I
worked around this by using prio-ceiling mutexes. That is by far not
optimal, performance-wise, but at least you avoid random lockups or the
other side effects of that bug.

> 
> Since the pSOS skin uses conditional variables to implement events and realtime
> priority threads to implement pSOS tasks, it is by definition broken
> and not useable
> for any real application.
> 
> For example the internal-timer server, sending events to lower priority tasks,
> will be blocked until all middle prio tasks have completed. We have seen
> massive load consumed by the internal-timer server due to this.
> What happens is that the timer thread is blocked on the mutex currently owned
> by an thread running at normal (lower) priority. Every time a Linux
> timer expires,
> a signal is sent to the timer-server which will wake-up the task,
> return to the c-library
> which will re-invoke the futex call. In case a high number of timers
> is used, the overhead
> of this can be large. Since the timer-server is running at the highest
> priority (-100) we
> see all kinds of strange crashes.
> 
> The same priority inversion is true for our own drivers since they are
> running at
> high prio as well.
> 
> Has the replacement of these conditional variables by some other POSIX mechanism
> (like mutexes) ever been considered?

Sometimes it is possible to design a algorithm that uses a semaphore for
event signaling instead. Doesn't work for all cond-var scenarios, though.

Jan

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