From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757463AbcHWMpx (ORCPT ); Tue, 23 Aug 2016 08:45:53 -0400 Received: from merlin.infradead.org ([205.233.59.134]:48678 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757358AbcHWMpv (ORCPT ); Tue, 23 Aug 2016 08:45:51 -0400 Date: Tue, 23 Aug 2016 14:45:19 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: Waiman Long , Jason Low , Ding Tianhong , Thomas Gleixner , Will Deacon , Ingo Molnar , Imre Deak , Linux Kernel Mailing List , Davidlohr Bueso , Tim Chen , Terry Rudd , "Paul E. McKenney" , Jason Low Subject: Re: [PATCH v4] locking/mutex: Prevent lock starvation when spinning is disabled Message-ID: <20160823124519.GB10138@twins.programming.kicks-ass.net> References: <1471567197.4991.41.camel@j-VirtualBox> <57B73A62.9020901@hpe.com> <20160819193315.GG10153@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 19, 2016 at 12:45:27PM -0700, Linus Torvalds wrote: > On Fri, Aug 19, 2016 at 12:33 PM, Peter Zijlstra wrote: > > > > That seems more messy to me.. > > Can't we just say that we always spin? Are there any really valid > cases where spinning isn't ok? > > We've historically disabled spinning when mutex debugging is enabled, > but since the spinning is limited anyway, couldn't we just spin even > with debugging enabled? > > I hate how these patches are trying to solve a problem that doesn't > even happen under normal circumstances, and add special-case code for > something that is already a special-case condition. So rather than > adding even more special cases, could we look at _removing_ the > special cases that cause problems instead? So I think I have a bunch of patches that solves the fundamental issues, _However_... they're quite invasive and would need some serious benchmarking. I'll post them in a separate thread as RFC..