From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932267AbdBGTxQ (ORCPT ); Tue, 7 Feb 2017 14:53:16 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:46908 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755156AbdBGTxO (ORCPT ); Tue, 7 Feb 2017 14:53:14 -0500 Date: Tue, 7 Feb 2017 11:53:08 -0800 From: "Paul E. McKenney" To: Waiman Long Cc: Ingo Molnar , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Linus Torvalds , Thomas Gleixner , Peter Zijlstra , Andrew Morton Subject: Re: [PATCH v3 0/3] locking/spinlock_debug: Change it to a mostly fair lock Reply-To: paulmck@linux.vnet.ibm.com References: <1486044929-7244-1-git-send-email-longman@redhat.com> <20170207084553.GW6500@twins.programming.kicks-ass.net> <20170207094816.GC9829@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17020719-0008-0000-0000-00000727141F X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006574; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000202; SDB=6.00818601; UDB=6.00400044; IPR=6.00596061; BA=6.00005123; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014214; XFM=3.00000011; UTC=2017-02-07 19:53:10 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17020719-0009-0000-0000-00003FB2EE8E Message-Id: <20170207195308.GY30506@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-07_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702070187 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 07, 2017 at 02:46:31PM -0500, Waiman Long wrote: > On 02/07/2017 04:48 AM, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > >> On Thu, Feb 02, 2017 at 09:15:26AM -0500, Waiman Long wrote: > >>> v2->v3: > >>> - Keep the original v1 patches but move patch 3 of v2 in front so > >>> as to disable GENERIC_LOCKBREAK when DEBUG_LOCK_ALLOC is on. > >>> > >>> v1->v2: > >>> - Pack lockup and break_lock into a single 4-byte slot so as not > >>> to in increase spinlock size when GENERIC_LOCKBREAK is > >>> on. Hopefully that will be enough to fix a frame size too large > >>> warning in 0-day build. > >>> - Add a new patch to disable GENERIC_LOCKBREAK when DEBUG_LOCK_ALLOC > >>> is on. > >>> > >>> The current debug spinlock implementation is a TATAS unfair lock. This > >>> can occasionally lead to system lockup with a debug kernel because > >>> of the unfairness of the lock rather than inherent locking problem. > >>> > >>> This patch set changes the debug spinlock implementation to a > >>> mostly fair spinlock based on the MCS lock similar to what is done > >>> in qspinlock. It also includes a patch that disable GENERIC_LOCKBREAK > >>> when DEBUG_LOCK_ALLOC is on. > >> > >> An alternative is to just delete the thing entirely.. > >> > >> Ingo, much of what this thing does seems to be superseded by both > >> lockdep and a reliable NMI watchdog. Is there still value in > >> spinlock_debug? > > So there's still early stages when the NMI watchdog is not running, and > > spinlock-debug can detect lockups in raw locks that lockdep does not cover, right? > > > > But yeah ... it would simplify things all around, so I'm not unsympathetic to the > > idea... > > > > I've Cc:-ed a few other locking gents. > > > > Thanks, > > > > Ingo > > I have no problem deleting the debug_spinlock code entirely. I can > update the patch to delete the code if you guys think that is the right > thing to do. > > Cheers, > Longman My usual question is "how often does the spinlock_debug code find a problem that would be hard to find otherwise?" Probably unanswerable given the nature of Linux-kernel development, but I figured I would ask anyway. ;-) Thanx, Paul