From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756024AbdCGSo3 (ORCPT ); Tue, 7 Mar 2017 13:44:29 -0500 Received: from merlin.infradead.org ([205.233.59.134]:59708 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755973AbdCGSo0 (ORCPT ); Tue, 7 Mar 2017 13:44:26 -0500 Date: Tue, 7 Mar 2017 12:42:04 +0100 From: Peter Zijlstra To: Byungchul Park Cc: mingo@kernel.org, tglx@linutronix.de, walken@google.com, boqun.feng@gmail.com, kirill@shutemov.name, linux-kernel@vger.kernel.org, linux-mm@kvack.org, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, npiggin@gmail.com, kernel-team@lge.com, Michal Hocko , Nikolay Borisov , Mel Gorman Subject: Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature Message-ID: <20170307114204.GA3312@twins.programming.kicks-ass.net> References: <1484745459-2055-1-git-send-email-byungchul.park@lge.com> <1484745459-2055-7-git-send-email-byungchul.park@lge.com> <20170228134018.GK5680@worktop> <20170301054323.GE11663@X58A-UD3R> <20170301122843.GF6515@twins.programming.kicks-ass.net> <20170302134031.GG6536@twins.programming.kicks-ass.net> <20170303001737.GF28562@X58A-UD3R> <20170303081416.GT6515@twins.programming.kicks-ass.net> <20170305030845.GA11100@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170305030845.GA11100@X58A-UD3R> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 05, 2017 at 12:08:45PM +0900, Byungchul Park wrote: > On Fri, Mar 03, 2017 at 09:14:16AM +0100, Peter Zijlstra wrote: > > > > Now the problem with the above condition is that it makes reports > > harder to decipher, because by avoiding adding redundant links to our > > graph we loose a possible shorter path. > > Let's see the following example: > > A -> B -> C > > where A, B and C are typical lock class. > > Assume the graph above was built and operations happena in the > following order: > > CONTEXT X CONTEXT Y > --------- --------- > acquire DX > acquire A > acquire B > acquire C > > release and commit DX > > where A, B and C are typical lock class, DX is a crosslock class. > > The graph will grow as following _without_ prev_gen_id. > > -> A -> B -> C > / / / > DX ----------- > > where A, B and C are typical lock class, DX is a crosslock class. > > The graph will grow as following _with_ prev_gen_id. > > DX -> A -> B -> C > > where A, B and C are typical lock class, DX is a crosslock class. > > You said the former is better because it has smaller cost in bfs. No, I said the former is better because when you report a DX inversion against C, A and B are not required and the report is easier to understand by _humans_. I don't particularly care about the BFS cost itself. > But it has to use _much_ more memory to keep additional nodes in > graph. Without exaggeration, every crosslock would get linked with all > locks in history locks, on commit, unless redundant. It might be > pretty more than we expect - I will check and let you know how many it > is. Is it still good? Dunno, probably not.. but it would be good to have numbers.