From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64383C4332F for ; Fri, 11 Feb 2022 05:55:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237156AbiBKFzm (ORCPT ); Fri, 11 Feb 2022 00:55:42 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235310AbiBKFzl (ORCPT ); Fri, 11 Feb 2022 00:55:41 -0500 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7577102F; Thu, 10 Feb 2022 21:55:40 -0800 (PST) Received: by mail-lj1-f175.google.com with SMTP id o17so11143142ljp.1; Thu, 10 Feb 2022 21:55:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nC1KApq7e2Tv1mRrJaVJbGFX4EPFBr5Wq82MxBaNzD0=; b=7kLiSQdB+67poBRL/OG48goLLOYPRN4hM0qliz9Rq72HKkp3z1sBsES/sKySUdj0DJ /shIxVGD3VlnCzaPHwaN+9ToowVByp9Xu/KaGXIvJWS7XtOkjti8OSh4ajo8Sr6EIUg8 6iF5o0H/JOlSffKiLmqeGw8TGCCngN+4ElqiE7zQPqtcWSpnHi/ll9Q6U6DlMAE4OY9J 2zCy2k2IMReMHZMZ9kIqOinhR7V/1uvyqaKfIxOnKB4d726JLn81tJqaXOU8vbfmFfxy NvdfH+ENthTDdZzwEweChOjZH8Fexp2Ubxih2CimR4VfSlXUwKFVaPGVSU+dqViCQmqb qbGw== X-Gm-Message-State: AOAM530Buvtn9WtnBpPB6BZ0tfZBhLZnTA8pWBimqxv/zhm8kbkusLYw 3qMXJ5pgg2j+QHltNe7lygHhqgI8h9u2b08wPBc= X-Google-Smtp-Source: ABdhPJzbOzw/0zV4IgkYBd1T8G0wbLX3SjAMswL8OAcpI2VPdwnBvfBks/G9AKwLofLucGjL/8xeS4WMPSxifL2SCtI= X-Received: by 2002:a05:651c:a04:: with SMTP id k4mr74921ljq.180.1644558938779; Thu, 10 Feb 2022 21:55:38 -0800 (PST) MIME-Version: 1.0 References: <20220208184208.79303-1-namhyung@kernel.org> <20220209090908.GK23216@worktop.programming.kicks-ass.net> In-Reply-To: From: Namhyung Kim Date: Thu, 10 Feb 2022 21:55:27 -0800 Message-ID: Subject: Re: [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1) To: Peter Zijlstra Cc: Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , LKML , Thomas Gleixner , Steven Rostedt , Byungchul Park , Mathieu Desnoyers , Radoslaw Burny , Tejun Heo , rcu , cgroups , linux-btrfs , intel-gfx , "Paul E. McKenney" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Thu, Feb 10, 2022 at 1:14 AM Peter Zijlstra wrote: > > On Wed, Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote: > > On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote: > > > > > > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote: > > > > > > > Eventually I'm mostly interested in the contended locks only and I > > > > want to reduce the overhead in the fast path. By moving that, it'd be > > > > easy to track contended locks with timing by using two tracepoints. > > > > > > So why not put in two new tracepoints and call it a day? > > > > > > Why muck about with all that lockdep stuff just to preserve the name > > > (and in the process continue to blow up data structures etc..). This > > > leaves distros in a bind, will they enable this config and provide > > > tracepoints while bloating the data structures and destroying things > > > like lockref (which relies on sizeof(spinlock_t)), or not provide this > > > at all. > > > > If it's only lockref, is it possible to change it to use arch_spinlock_t > > so that it can remain in 4 bytes? It'd be really nice if we can keep > > spin lock size, but it'd be easier to carry the name with it for > > analysis IMHO. > > It's just vile and disgusting to blow up the lock size for convenience > like this. > > And no, there's more of that around. A lot of effort has been spend to > make sure spinlocks are 32bit and we're not going to give that up for > something as daft as this. > > Just think harder on the analysis side. Like said; I'm thinking the > caller IP should be good enough most of the time. Ok, I'll go in this direction then. So you are ok with adding two new tracepoints, even if they are similar to what we already have in lockdep/lock_stat, right? Thanks, Namhyung From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A1ABDC433EF for ; Fri, 11 Feb 2022 05:55:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1225510E860; Fri, 11 Feb 2022 05:55:42 +0000 (UTC) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by gabe.freedesktop.org (Postfix) with ESMTPS id D275F10E860 for ; Fri, 11 Feb 2022 05:55:40 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id k10so8102967ljq.2 for ; Thu, 10 Feb 2022 21:55:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nC1KApq7e2Tv1mRrJaVJbGFX4EPFBr5Wq82MxBaNzD0=; b=vx57QRjEGqJpJCtfXK1DrFryipPK6uDn1KEuNQGCsCV/XjnERywgqX5u2pdpDNUrPo fo6Qq2I2imj5HZrSlbL9EFNpevpAKCuIKTfwzJyEZi8CWTP9M2bV3hlg74JIoGHKlmuk mfskcHAC8XQ0G5lS9g92vrYxZnJFpZOiXRCUlG+xO+o8cAvP841rjVkix/Xw1GCAwbIb alvumzxHKfMLMckLVNyiC/vM+YOXejse+NxKnOkbWugo0Z4DhgDalWGrpMWqYZnKS/UX NdCr5wg7AW4tEYXALjgPk6UJjFUCEcUQkVw7mEb/waXphI59Rt6pCvpHKxaMIjXO4no4 CRow== X-Gm-Message-State: AOAM530Nt+T70MDlzvh0STnxHszy3qQ4s3tlAVRuwGzSNap7QcHx8fIY RuC1BleudLDqpA0W1lQGg2fK8JcPdG52ByHqRr8= X-Google-Smtp-Source: ABdhPJzbOzw/0zV4IgkYBd1T8G0wbLX3SjAMswL8OAcpI2VPdwnBvfBks/G9AKwLofLucGjL/8xeS4WMPSxifL2SCtI= X-Received: by 2002:a05:651c:a04:: with SMTP id k4mr74921ljq.180.1644558938779; Thu, 10 Feb 2022 21:55:38 -0800 (PST) MIME-Version: 1.0 References: <20220208184208.79303-1-namhyung@kernel.org> <20220209090908.GK23216@worktop.programming.kicks-ass.net> In-Reply-To: From: Namhyung Kim Date: Thu, 10 Feb 2022 21:55:27 -0800 Message-ID: To: Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Subject: Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1) X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rcu , "Paul E. McKenney" , intel-gfx , Boqun Feng , LKML , Steven Rostedt , Radoslaw Burny , Byungchul Park , Mathieu Desnoyers , cgroups , Tejun Heo , Waiman Long , Thomas Gleixner , Will Deacon , Ingo Molnar , linux-btrfs Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, Feb 10, 2022 at 1:14 AM Peter Zijlstra wrote: > > On Wed, Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote: > > On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote: > > > > > > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote: > > > > > > > Eventually I'm mostly interested in the contended locks only and I > > > > want to reduce the overhead in the fast path. By moving that, it'd be > > > > easy to track contended locks with timing by using two tracepoints. > > > > > > So why not put in two new tracepoints and call it a day? > > > > > > Why muck about with all that lockdep stuff just to preserve the name > > > (and in the process continue to blow up data structures etc..). This > > > leaves distros in a bind, will they enable this config and provide > > > tracepoints while bloating the data structures and destroying things > > > like lockref (which relies on sizeof(spinlock_t)), or not provide this > > > at all. > > > > If it's only lockref, is it possible to change it to use arch_spinlock_t > > so that it can remain in 4 bytes? It'd be really nice if we can keep > > spin lock size, but it'd be easier to carry the name with it for > > analysis IMHO. > > It's just vile and disgusting to blow up the lock size for convenience > like this. > > And no, there's more of that around. A lot of effort has been spend to > make sure spinlocks are 32bit and we're not going to give that up for > something as daft as this. > > Just think harder on the analysis side. Like said; I'm thinking the > caller IP should be good enough most of the time. Ok, I'll go in this direction then. So you are ok with adding two new tracepoints, even if they are similar to what we already have in lockdep/lock_stat, right? Thanks, Namhyung From mboxrd@z Thu Jan 1 00:00:00 1970 From: Namhyung Kim Subject: Re: [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1) Date: Thu, 10 Feb 2022 21:55:27 -0800 Message-ID: References: <20220208184208.79303-1-namhyung@kernel.org> <20220209090908.GK23216@worktop.programming.kicks-ass.net> Mime-Version: 1.0 Return-path: In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Peter Zijlstra Cc: Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , LKML , Thomas Gleixner , Steven Rostedt , Byungchul Park , Mathieu Desnoyers , Radoslaw Burny , Tejun Heo , rcu , cgroups , linux-btrfs , intel-gfx , "Paul E. McKenney" On Thu, Feb 10, 2022 at 1:14 AM Peter Zijlstra wrote: > > On Wed, Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote: > > On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote: > > > > > > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote: > > > > > > > Eventually I'm mostly interested in the contended locks only and I > > > > want to reduce the overhead in the fast path. By moving that, it'd be > > > > easy to track contended locks with timing by using two tracepoints. > > > > > > So why not put in two new tracepoints and call it a day? > > > > > > Why muck about with all that lockdep stuff just to preserve the name > > > (and in the process continue to blow up data structures etc..). This > > > leaves distros in a bind, will they enable this config and provide > > > tracepoints while bloating the data structures and destroying things > > > like lockref (which relies on sizeof(spinlock_t)), or not provide this > > > at all. > > > > If it's only lockref, is it possible to change it to use arch_spinlock_t > > so that it can remain in 4 bytes? It'd be really nice if we can keep > > spin lock size, but it'd be easier to carry the name with it for > > analysis IMHO. > > It's just vile and disgusting to blow up the lock size for convenience > like this. > > And no, there's more of that around. A lot of effort has been spend to > make sure spinlocks are 32bit and we're not going to give that up for > something as daft as this. > > Just think harder on the analysis side. Like said; I'm thinking the > caller IP should be good enough most of the time. Ok, I'll go in this direction then. So you are ok with adding two new tracepoints, even if they are similar to what we already have in lockdep/lock_stat, right? Thanks, Namhyung