Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp476525imm; Mon, 9 Jul 2018 05:26:46 -0700 (PDT) X-Google-Smtp-Source: AAOMgpek+jDQGTw/97z0DnUtJTHfoW31kWNmCDHtix32GeA2X02F6VW7BHIVQWOhByvMrVJzI4Zn X-Received: by 2002:a17:902:2d24:: with SMTP id o33-v6mr20508520plb.14.1531139206300; Mon, 09 Jul 2018 05:26:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531139206; cv=none; d=google.com; s=arc-20160816; b=d+NSScuqQqBlhJSqiOKmFVS5ZxEvbcb574La4vptfs2Bxf1Rw172c1EXwGO+pfUyQu 5f758Mq2Ht/WXt/YPOG4zZyqG1K0ZalJppwd7+LKiBpvMsWyszdPFITUPkRAtPkB/0KW RZy7gne/ilAKD6yVZWJXDn+KH6qqdY8EbV/IgpCVIDh9/XPAF681H/u78Y0DB2NhC2fY E0wiJiDlOvNk9BrgGRqgyseQjuRZzfyEjBqEABH7C9J5IFpjhoR0huHLYIUtzlgwpcdQ KuPs17fhlV/0X5YIDcDGezC1V/cRBiXDvYDOS/cZJQqIw4ZpnemNzxFDUXyt4V/yRYaf 0Bvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=7zEOY1GJq7LkCkUETKlcjYGHuBxiIO/jayJwisyVaYM=; b=B4Tk+fYlnZDdLpLIq3tbOm8kJMLQL2jfvDs5Zk0phWwNcmKzntMLfdF37Dmi/FVijB dVy1zZ5eaT68YPXf5ehgPvAfJe92TBni9HW1TN4znkybWdvpHe+3KZZaOzDOZ51kp/i1 alZcwvIKpFDDxr0j9nK7y29lVsc8wG/4sUfTOErjXxEj2rnLEbdTzYPMQB9pAuZlWcvG 5xzhtGmltIrnJtAK/ybRWSMDsvbQGJ247wq6OOF5fWkj0r5GcQDwpbdTr8+48mJsndn8 PiZL7r0GT4zh4w+DJ0gsth9gQ6fE80F8nciJkVUZxTHlqsi5CedwSfd3egzQkbs9Ou14 gC1Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a85-v6si16535583pfa.109.2018.07.09.05.26.31; Mon, 09 Jul 2018 05:26:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933119AbeGIMZj (ORCPT + 99 others); Mon, 9 Jul 2018 08:25:39 -0400 Received: from smtp1.de.adit-jv.com ([62.225.105.245]:49394 "EHLO smtp1.de.adit-jv.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932797AbeGIMZh (ORCPT ); Mon, 9 Jul 2018 08:25:37 -0400 Received: from localhost (smtp1.de.adit-jv.com [127.0.0.1]) by smtp1.de.adit-jv.com (Postfix) with ESMTP id EC9AE3C015E; Mon, 9 Jul 2018 14:25:34 +0200 (CEST) Received: from smtp1.de.adit-jv.com ([127.0.0.1]) by localhost (smtp1.de.adit-jv.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKqtIr8A4ZVo; Mon, 9 Jul 2018 14:25:28 +0200 (CEST) Received: from HI2EXCH01.adit-jv.com (hi2exch01.adit-jv.com [10.72.92.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.de.adit-jv.com (Postfix) with ESMTPS id 431263C09A0; Mon, 9 Jul 2018 14:25:28 +0200 (CEST) Received: from vmlxhi-102.adit-jv.com (10.72.93.184) by HI2EXCH01.adit-jv.com (10.72.92.24) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 9 Jul 2018 14:25:27 +0200 Date: Mon, 9 Jul 2018 14:25:24 +0200 From: Eugeniu Rosca To: Peter Zijlstra , Viresh Kumar , "Rafael J . Wysocki" CC: Eugeniu Rosca , Ingo Molnar , Thomas Gleixner , , Will Deacon , Viresh Kumar , "Rafael J . Wysocki" , Steven Rostedt , Byungchul Park , Tetsuo Handa , Eugeniu Rosca Subject: Re: [PATCH] locking/lockdep: Report comm/pid/timestamp information Message-ID: <20180709122524.GA30596@vmlxhi-102.adit-jv.com> References: <20180709005725.18184-1-erosca@de.adit-jv.com> <20180709083118.GA2476@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20180709083118.GA2476@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.72.93.184] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 09, 2018 at 10:31:18AM +0200, Peter Zijlstra wrote: > On Mon, Jul 09, 2018 at 02:57:25AM +0200, Eugeniu Rosca wrote: > > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > > index 6fc77d4dbdcd..eeed7ea2e198 100644 > > --- a/include/linux/lockdep.h > > +++ b/include/linux/lockdep.h > > @@ -186,6 +186,10 @@ struct lock_list { > > struct list_head entry; > > struct lock_class *class; > > struct stack_trace trace; > > + unsigned long long ts; > > + char comm[16]; > > + pid_t pid; > > + int cpu; > > int distance; > > > > /* > > Yeah, not going to happen. You grow that structure from 64 bytes to 96 > bytes and with that grow the static footprint of the kernel by 512k (in > the very best case) I confirm that in case of x86_64, the bss size is increased by ~1M [1] with standard v4.18-rc4 x86_64_defconfig + CONFIG_LOCKDEP. > possibly again breaking things like sparc (which > have a strict limit on the kernel image size). For sparc there seems to be a dedicated CONFIG_LOCKDEP_SMALL, which seems to downsize the lockdep implementation anyway. > And all that for data that I've never needed and never even considered > useful when looking at lockdep output. It's likely because you infer about certain aspects which are not clearly stated in the deadlock report. As example, the original report doesn't say that the process which holds 'cpu_hotplug_lock.rw_sem' is different to the process which holds the other locks. On the contrary, it tells the user that all the locks are being held by the same task, which seems to be wrong. You likely also infer about the order of consuming the locks based on the contents of the stack dump associated to each lock. Without doing some mental diffs between the backtraces, it's not possible to see the chronological order of consuming the locks. Actually this only works for backtraces with common history, i.e. there is no clue what is the time/point of acquiring 'cpu_hotplug_lock.rw_sem' relative to the other locks. The patch mostly shares my personal experience of trying to make sense of lockdep output. It's OK if it doesn't reach mainline. I still hope that I can get some feedback from community regarding the actual cpufreq-related issue pointed out in the splat. I can also reproduce it on v4.14, so it appears to be in the kernel for quite some time. Thank you in advance. Best regards, Eugeniu. [1] BSS size increase after applying the patch $ bloaty -s vm vmlinux.after -- vmlinux.before VM SIZE FILE SIZE -------------- -------------- +8.2% +1024Ki .bss 0 [ = ] ----snip---- +2.6% +1024Ki TOTAL +3.36Ki +0.0%