Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758008AbcDHOvV (ORCPT ); Fri, 8 Apr 2016 10:51:21 -0400 Received: from www.linutronix.de ([62.245.132.108]:52053 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752258AbcDHOvT (ORCPT ); Fri, 8 Apr 2016 10:51:19 -0400 Subject: Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule To: Mike Galbraith References: <1455318168-7125-1-git-send-email-bigeasy@linutronix.de> <1455318168-7125-4-git-send-email-bigeasy@linutronix.de> <1458463425.3908.5.camel@gmail.com> <1458814024.23732.35.camel@gmail.com> <1459405903.14336.64.camel@gmail.com> <20160401211105.GE29603@linutronix.de> <1459566735.3779.36.camel@gmail.com> <57068F28.8010409@linutronix.de> <1460123044.16946.11.camel@gmail.com> <5707B911.6090404@linutronix.de> <1460125010.16946.27.camel@gmail.com> Cc: Thomas Gleixner , linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org, Steven Rostedt , Peter Zijlstra From: Sebastian Andrzej Siewior Message-ID: <5707C563.2050801@linutronix.de> Date: Fri, 8 Apr 2016 16:51:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <1460125010.16946.27.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 791 Lines: 21 On 04/08/2016 04:16 PM, Mike Galbraith wrote: >> okay. and how did you trigger this? Just Steven's script or was there >> more to it? > > I run stockfish, futextest, hackbench and tbench with it, terminating > and restarting them at random intervals just to make sure nobody gets > into a comfortable little rut. Stockfish and tbench are sized as to > not saturate the box, hackbench runs periodically (and with no args to > turn it into a hog), futextest run.sh just does its normal thing. Is there anything you can hand me over? > Trying to grab an rtmutex while queued on an rtmutex... doesn't matter > much if it's the lock that likes to deadlock us, or the one you added > instead of making that blasted lock really really dead. Yeah, doesn't look too good. > -Mike > Sebastian