From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758032AbdJMJHy (ORCPT ); Fri, 13 Oct 2017 05:07:54 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:41445 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757515AbdJMJHw (ORCPT ); Fri, 13 Oct 2017 05:07:52 -0400 Date: Fri, 13 Oct 2017 11:07:44 +0200 From: Peter Zijlstra To: Johan Hovold Cc: Byungchul Park , Ingo Molnar , 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: <20171013090744.lvvc66qexmomsd5f@hirez.programming.kicks-ass.net> 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/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 13, 2017 at 11:03:33AM +0200, 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? Expected yes, desirable not so much. Its the save_stack_trace() in add_xhlock() (IIRC). I've not yet had time to figure out what to do about that.