From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5492D80E.3010701@siemens.com> Date: Thu, 18 Dec 2014 14:35:10 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <549072DC.1030901@xenomai.org> <549090FA.7000901@xenomai.org> <5492989C.9070106@siemens.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] [xenomai-forge] timer-internal consume a lot of cpu List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ronny Meeus Cc: xenomai@xenomai.org On 2014-12-18 13:28, Ronny Meeus wrote: > On Thu, Dec 18, 2014 at 10:04 AM, Jan Kiszka 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