Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751667AbdH3M1r (ORCPT ); Wed, 30 Aug 2017 08:27:47 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:34734 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751326AbdH3M1o (ORCPT ); Wed, 30 Aug 2017 08:27:44 -0400 Date: Wed, 30 Aug 2017 21:30:07 +0900 From: Sergey Senozhatsky To: Peter Zijlstra Cc: Sergey Senozhatsky , 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: <20170830123007.GA6460@jagdpanzerIV.localdomain> 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> <20170830084207.GL32112@worktop.programming.kicks-ass.net> <20170830084746.GC660@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170830084746.GC660@worktop.programming.kicks-ass.net> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 773 Lines: 30 Hello Peter, On (08/30/17 10:47), Peter Zijlstra wrote: [..] > On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote: > > > > 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. > > Aah, we do an unconditional stack unwind for every __lock_acquire() now. > It keeps a trace in the xhlocks[]. > > Does the below cure most of that overhead? thanks. mostly yes. the kernel is not so dramatically slower now. it's still seems to be a bit slower, which is expected I suppose, but over all it's much better real 1m35.209s user 4m12.467s sys 0m49.457s // approx 10 seconds slower. -ss