From patchwork Wed Aug 30 08:42:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Zijlstra X-Patchwork-Id: 9928933 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1267C60380 for ; Wed, 30 Aug 2017 08:42:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0225B28111 for ; Wed, 30 Aug 2017 08:42:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EB24F28173; Wed, 30 Aug 2017 08:42:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A58928111 for ; Wed, 30 Aug 2017 08:42:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751341AbdH3ImV (ORCPT ); Wed, 30 Aug 2017 04:42:21 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:53109 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbdH3ImT (ORCPT ); Wed, 30 Aug 2017 04:42:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gmd6pH0Vk01kUBDhkOvVrzNvbfK8OERMQiP+hfsdpkI=; b=lmNlAokXHcuOnky7Gy/3LdaDe 8KLqqer5sXQz+AesqgkKEIragkNACweOhZwpIlEp+gEXQdZV32er3gIwusqxFF8tcvfi8cByJBvPI A7wqdf9hlaTjPb7yBW4L+Bp6tni7mxRgrvak1bb2yC44Dmq3wdpWKH5tX8ZCxE2qqB/0CU6o5nZbN /1Z0scK2blBliSIkdrAqQibms4zcynzIS3QHGWdeali9xmRoKSlfdrxf9cXVXxzFjyapeeoMU3ejA gfISHZhi8LlMH9JKuV7yOpGtkX8UZU0zZs2cO/MHKX2mgTiGhxJn81kEQezKBtc8qD36GycPoI8WY nLZHc6KRQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop) by bombadil.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1dmyZe-0006rb-Ja; Wed, 30 Aug 2017 08:42:11 +0000 Received: by worktop (Postfix, from userid 1000) id 4C3676E06BA; Wed, 30 Aug 2017 10:42:07 +0200 (CEST) Date: Wed, 30 Aug 2017 10:42:07 +0200 From: Peter Zijlstra To: Sergey Senozhatsky Cc: Byungchul Park , Bart Van Assche , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "martin.petersen@oracle.com" , "axboe@kernel.dk" , "linux-scsi@vger.kernel.org" , "sfr@canb.auug.org.au" , "linux-next@vger.kernel.org" , kernel-team@lge.com Subject: Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22] Message-ID: <20170830084207.GL32112@worktop.programming.kicks-ass.net> References: <20170822183816.7925e0f8@canb.auug.org.au> <20170822104708.GA491@jagdpanzerIV.localdomain> <1503438234.2508.27.camel@wdc.com> <20170823000304.GK20323@X58A-UD3R> <20170830052037.GA432@jagdpanzerIV.localdomain> <20170830054334.GF3240@X58A-UD3R> <20170830061511.GA330@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170830061511.GA330@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Aug 30, 2017 at 03:15:11PM +0900, Sergey Senozhatsky wrote: > Hi, > > On (08/30/17 14:43), Byungchul Park wrote: > [..] > > > notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim > > > is irritatingly slow) > > > > To Ingo, > > > > I cannot decide if we have to roll back CONFIG_LOCKDEP_CROSSRELEASE > > dependency on CONFIG_PROVE_LOCKING in Kconfig. With them enabled, > > lockdep detection becomes strong but has performance impact. But, > > it's anyway a debug option so IMHO we don't have to take case of the > > performance impact. Please let me know your decision. > > well, I expected it :) > > I've been running lockdep enabled kernels for years, and was OK with > the performance. but now it's just too much and I'm looking at disabling > lockdep. > > a more relevant test -- compilation of a relatively small project > > LOCKDEP -CROSSRELEASE -COMPLETIONS LOCKDEP +CROSSRELEASE +COMPLETIONS > > real 1m23.722s real 2m9.969s > user 4m11.300s user 4m15.458s > sys 0m49.386s sys 2m3.594s > > > you don't want to know how much time now it takes to recompile the > kernel ;) Right,.. so when I look at perf annotate for __lock_acquire and lock_release (the two most expensive lockdep functions in a kernel profile) I don't actually see much cross-release stuff. So the overhead looks to be spread out over all sorts, which makes it harder to find and fix. stack unwinding is done lots and is fairly expensive, I've not yet checked if crossrelease does too much of that. The below saved about 50% of my __lock_acquire() time, not sure it made a significant difference over all though. diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 44c8d0d17170..f8db1ead1c48 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -3386,7 +3386,7 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass, if (!class) return 0; } - atomic_inc((atomic_t *)&class->ops); + /* atomic_inc((atomic_t *)&class->ops); */ if (very_verbose(class)) { printk("\nacquire class [%p] %s", class->key, class->name); if (class->name_version > 1)