From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753966AbdFSLbl convert rfc822-to-8bit (ORCPT ); Mon, 19 Jun 2017 07:31:41 -0400 Received: from mout.gmx.net ([212.227.15.18]:64868 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753711AbdFSLbk (ORCPT ); Mon, 19 Jun 2017 07:31:40 -0400 Message-ID: <1497871888.19618.90.camel@gmx.de> Subject: Re: [ANNOUNCE] v4.11.5-rt1 From: Mike Galbraith To: Sebastian Andrzej Siewior Cc: Thomas Gleixner , LKML , linux-rt-users , Steven Rostedt Date: Mon, 19 Jun 2017 13:31:28 +0200 In-Reply-To: <20170619104459.prmicsbbmljc6smb@linutronix.de> References: <20170616105610.rbc6itylcrsla56l@linutronix.de> <1497687277.6908.31.camel@gmx.de> <20170619085206.n2n22lpdfsoqbp5m@linutronix.de> <1497867291.19618.52.camel@gmx.de> <20170619104459.prmicsbbmljc6smb@linutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:XJ+cTyVYD2/UPRKxVvTZc9aBRgCW43B/Q8r11m4x7JkDpNDXHIp OyQ2bR/JifeGovZVpZt6g6Z8Edh/uJMXbOZ4ThrR7Ya/Wl3JdSGICZS7WGy5lqvhH5DdsdE QMEAZrB+5QZc0jpMVxNS9EY989T8fFWLSxHMImDi99NJ+/GpvQsYPTip0iHzU0dwbo1p7x3 CG63ROluxKzBOhx6AyKWQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:CCPalMhMspY=:zevni783hoAo7ZymrOiTqR X7kS/lYUYZfAS25C6xKMpbaB+F9jZkzlMSEPhaWaW85bNpx74Z/cAaVJ8lUZjM82hBYMBznfR XnfkrL7NL6P28Y3vTA4ZzR1G8getvrszXYOQo+Bd6bzYm45uIj92oOyRxDQuFZQdNhXP+RTAe 30/m55AvoMVewIu5wJpnknOiZZ8CDru6D2JQ76baqW5KngAMi4bdSn3hqHNMKhfiLCTiykJ7n Y5vAS/164P5mmjphiKx6z2q+zpDB+E/jtSwRYY/XdhZZ+nFQKpR5J1jnOvOC3kvMGwZeYJzW+ hMQaa2ajnPLBEVJ0KWC006FSpwPgvxNkNxrwFWOGNWlPtBzNc2jBduE3ILeOowo/sv053w3Ma Mpc5ZbFDbvdN4A/BBnM5YVTErjsl3GO56rZPR0cI5WY5Q8bjNOuSvvkmbckfOXCbKtRGzUPVN 4XlpaIvrbg91dUz7WR4+hS03nxmpTYKNCiWqE9al8YFPcZ6rmd5ophcJO5apM3jrZzgreIzlE 23rinMzDoh9uf8iReDkM4Re0rAU+fDZUBTQEn30lW0OI+xWR0VC/voN6Dgp9QCKJVoqz5l/wH iaR5LXdlGOy9HkV3+sJ4cCJTLcvUlE60SA+/u2NsLA93iJDnyKxWw47AhhSU2AeXgqQnJcaUt yh9Uf2bxoip6EVae5RLGZ20I042+J/eE5TYrVsrfEz1vpJM1h/P9O1jiJLGDwxW1qeOGJGvw6 DYHMWOBQI5bP48GItLAplL/Fi+PJPlJfSso6ZspkCmhL3vjv9+wb/uvZMTghcrwOkV+drPMWO aO9E5Od Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-06-19 at 12:44 +0200, Sebastian Andrzej Siewior wrote: > On 2017-06-19 12:14:51 [+0200], Mike Galbraith wrote: > > Ok, doesn't matter for RT testing. What does matter, is that... > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index 30b24f774198..10e832da70b6 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -2284,7 +2284,7 @@ EXPORT_SYMBOL(wake_up_process); > > */ > > int wake_up_lock_sleeper(struct task_struct *p) > > { > > - return try_to_wake_up(p, TASK_ALL, WF_LOCK_SLEEPER); > > + return try_to_wake_up(p, TASK_UNINTERRUPTIBLE, WF_LOCK_SLEEPER); > > } > > > > ...appears to be inducing lost futex wakeups. > > has this something to do with "rtmutex: Fix lock stealing logic" ? Nope.  The above is fallout of me being inspired me to stare, that inspiration having come initially from seeing lost wakeup symptoms in my desktop, telling me something has gone sour in rt-land, so a hunting I did go.  I expected to find I had made a booboo in my trees, but maybe not, as I found a suspiciously similar symptom to what I was looking for in virgin source. > > Scratch that "appears", changing it to TASK_NORMAL just fixed my DL980 > > running otherwise absolutely pristine 4.9-rt21, after having double > > verified that rt20 works fine.  Now to go back to 4.11/master/tip-rt, > > make sure that the little bugger really really REALLY ain't fscking > > with me for the sheer fun of it, futexes being made of pure evil :) > > So v4.9-rt20 works fine but -rt21 starts to lose wakeups on DL980 in > general or just with "futex_wait -n 4" ? -rt20 is verified to work fine, -rt21 starts hanging with futextest.  The futex_wait -n 4 testcase was distilled out of seeing the full futextest/run.sh hanging.  The only symptom I've _seen_ on the DL980 is futextest hanging.  On the desktop, I've seen more, and may still, I'll know when I see or don't see desktop gizmos occasionally go comatose. > > My testcase is to run futex_wait -n 4 in a modest sized loop.  Odd > > thing is that it only reproduces on the DL980 if I let it use multiple > > sockets, pin it to one, and all is peachy, (rather seems to be given) > > whereas on desktop box, the hang is far more intermittent, but there. > > do I parse it right, as v4.9-rt21 (without the change above) works with > the testcase mentioned if you pin it to one socket but does not work if > you let it use multiple sockets. > And your desktop box hangs no matter what? No no, desktop box will reproduce, but not nearly as reliably as the 8 socket box does, but yes, it seems to work fine on the DL980 when pinned to one socket.  I was testing 4.9-rt because hunt was in progress when 4.11-rt was born. -Mike