From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752104AbcJBKBy (ORCPT ); Sun, 2 Oct 2016 06:01:54 -0400 Received: from smtprelay0238.hostedemail.com ([216.40.44.238]:53694 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750912AbcJBKBn (ORCPT ); Sun, 2 Oct 2016 06:01:43 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1539:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2693:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3874:4559:5007:6261:7875:7903:10004:10400:10848:10967:11232:11658:11914:12740:12760:13069:13161:13229:13311:13357:13439:14096:14097:14181:14659:21080:21094:21324:21433:30045:30054:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: love33_48e544191a12e X-Filterd-Recvd-Size: 1745 Date: Sun, 2 Oct 2016 06:01:37 -0400 From: Steven Rostedt To: Thomas Gleixner Cc: Sebastian Andrzej Siewior , linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org, peterz@infradead.org Subject: Re: [PATCH RT] kernel/futex: don't deboost too early Message-ID: <20161002060137.2716b089@grimm.local.home> In-Reply-To: References: <20160930083913.aqjpynzsj5d3xxho@linutronix.de> <20160930120038.5fe7d535@grimm.local.home> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 Sep 2016 20:43:26 +0200 (CEST) Thomas Gleixner wrote: > On Fri, 30 Sep 2016, Steven Rostedt wrote: > > This looks awfully complex. Would something as simple as this work? > > > > What harm can happen by moving the holding of the lock after the > > wakeups for RT? > > That's exactly bringing us back to the state before we added the delayed > wakeup so that the woken waiter will not be blocked on hb->lock right > away. That's 2 extra context switches for nothing. Ah crap, that's the wake up of the owner that's about to grab the lock, in which case (if on the same CPU) may preempt this guy, just to grab the hb->lock and block again. Grumble, how come the easy way is never a possibility :-p -- Steve