From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751815AbdJNH1H (ORCPT ); Sat, 14 Oct 2017 03:27:07 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:37345 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751737AbdJNH1E (ORCPT ); Sat, 14 Oct 2017 03:27:04 -0400 X-Google-Smtp-Source: AOwi7QBzc/lnB/wzKmerzbCgHCdLb+sUhli89tc4WaBLB4+EjBQDtir6HOPvyxNkWmK+ukpKQp+RlQ== Date: Sat, 14 Oct 2017 09:26:59 +0200 From: Ingo Molnar To: Johan Hovold Cc: Byungchul Park , Peter Zijlstra , linux-kernel@vger.kernel.org, tglx@linutronix.de, linux-mm@kvack.org, kernel-team@lge.com, Tony Lindgren , Arnd Bergmann , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: Dramatic lockdep slowdown in 4.14 Message-ID: <20171014072659.f2yr6mhm5ha3eou7@gmail.com> References: <20171013090333.GA17356@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171013090333.GA17356@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Johan Hovold wrote: > Hi, > > I had noticed that the BeagleBone Black boot time appeared to have > increased significantly with 4.14 and yesterday I finally had time to > investigate it. > > Boot time (from "Linux version" to login prompt) had in fact doubled > since 4.13 where it took 17 seconds (with my current config) compared to > the 35 seconds I now see with 4.14-rc4. > > I quick bisect pointed to lockdep and specifically the following commit: > > 28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition > of a crosslock") > > which I've verified is the commit which doubled the boot time (compared > to 28a903f63ec0^) (added by lockdep crossrelease series [1]). > > I also verified that simply disabling CONFIG_PROVE_LOCKING on 4.14-rc4 > brought boot time down to about 14 seconds. > > Now since it's lockdep I guess this can't really be considered a > regression if these changes did improve lockdep correctness, but still, > this dramatic slow down essentially forces me to disable PROVE_LOCKING > by default on this system. > > Is this lockdep slowdown expected and desirable? It's not desirable at all. Does the patch below fix the regression for you - or does the introduction and handling of ->nr_acquire hurt as well? Thanks, Ingo ====================> lib/Kconfig.debug | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c6401d325b0e..f5b40c1668ea 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1138,8 +1138,8 @@ config PROVE_LOCKING select DEBUG_MUTEXES select DEBUG_RT_MUTEXES if RT_MUTEXES select DEBUG_LOCK_ALLOC - select LOCKDEP_CROSSRELEASE - select LOCKDEP_COMPLETIONS +# select LOCKDEP_CROSSRELEASE +# select LOCKDEP_COMPLETIONS select TRACE_IRQFLAGS default n help