From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <549072DC.1030901@xenomai.org> Date: Tue, 16 Dec 2014 18:58:52 +0100 From: Philippe Gerum MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 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 , xenomai@xenomai.org On 12/16/2014 06:36 PM, Ronny Meeus wrote: > On Sun, Dec 7, 2014 at 5:26 PM, Ronny Meeus wrote: >> Hello >> >> we are using the xenomai-forge implementation. >> We from time to time see an issue that the timer-internal thread is >> consuming a complete core. It is seen when we send broadcast traffic that >> needs to be handled by the Linux kernel (ARP). >> >> The kernel thread's priority handling the packets in the middle between the >> timer-internal thread and the application thread's priority. All threads run >> on the same core. >> If the priority of the timer-internal is lowered below the kernel thread, >> the load disappears immediately. >> So it looks like there is some busy polling on a common resource that is >> currently held by the application thread running at the lowest prio. >> >> I see that the timer lock being used is a mutex with priority inheritance so >> I would expect that the prio of the application is raised as soon as the >> timer-internal thread tries to obtain the mutex. > > After investigating this issue in more detail I have the impression that it has > nothing to do with the mutex used to protect the timer but with the conditional > variable used to implement the psos event interface. > > I found references on the web that explain an issue with the internal mutex used > inside the posix library to implement a conditional variable. See: > https://bugzilla.redhat.com/show_bug.cgi?id=438484 > http://marc.info/?t=134688711000002&r=1&w=2 > > If this is indeed true, it means that the usage of conditional > variables is not safe > at all (from priority inheritance point of view). Yes, condvars are known not to work nicely with PI mutexes on the glibc. > > Did anybody experiences issues like this before? > Are there any solutions / workarounds available (for example by avoiding using > conditional variables and using PI mutexes instead)? Disabling PI for mutexes is the only option. -- Philippe.