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 E9CA1C4332F for ; Tue, 1 Mar 2022 18:26:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236911AbiCAS0l (ORCPT ); Tue, 1 Mar 2022 13:26:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229944AbiCAS0i (ORCPT ); Tue, 1 Mar 2022 13:26:38 -0500 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3377C6515F; Tue, 1 Mar 2022 10:25:56 -0800 (PST) Received: by mail-lj1-f181.google.com with SMTP id v28so22984767ljv.9; Tue, 01 Mar 2022 10:25:56 -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=s6DUiFskOYbQ+Ck/lkK1O7UIc++6NtzCSpAL7foCAE4=; b=SDv7X3qt6ybmSVewm7n/0RtrbUEzeF7dyQUSa17W2PJBCEmGdcgx2ljOJHF34QStqk KkNnLCbl0Q6QsohgMQzEhfsJuu9ox414/P9tVbTSR1Eg5e9FxbQhv/7wBc5wwqEyCpWD 13/2PzvTsU7L85NX29DrQVRGiiM9J5VhPxDjDmukQYySfdwynp6STw8RrAgSwdhSDBtc MQj7BHB5+nFgHo6Txrz1VyMLJ4UbHN6ksTlyebIN1Os+AeKTVRGcb+hkQgIUfoOAGvIv yx2qhQ2EUarpyUZX1S2NvXJbSe2hFIaxVsfFLbOeQ1OBg67WVEqmA97Q/NyHo8gHR3Uq KgIg== X-Gm-Message-State: AOAM532lJ7uYcOiR84I10snrI+6ktMa2CjH0Jq0f7i/mdja6N4ZQfLeG 6Rop7YgPxcfaeqhbNUMADPHIyj57Lt3S0khTV2Q= X-Google-Smtp-Source: ABdhPJyZU9iweug4accW/5RqwICgEq7TDb7Oq+GIai7exNilWqkOUuniSKsc3XQFAMYeYyKFfMFd0LqcEw1skYuKsxI= X-Received: by 2002:a2e:891a:0:b0:246:293f:875e with SMTP id d26-20020a2e891a000000b00246293f875emr17268761lji.204.1646159154549; Tue, 01 Mar 2022 10:25:54 -0800 (PST) MIME-Version: 1.0 References: <20220301010412.431299-1-namhyung@kernel.org> <20220301010412.431299-4-namhyung@kernel.org> In-Reply-To: From: Namhyung Kim Date: Tue, 1 Mar 2022 10:25:43 -0800 Message-ID: Subject: Re: [PATCH 3/4] locking/mutex: Pass proper call-site ip To: Peter Zijlstra Cc: Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , LKML , Thomas Gleixner , Steven Rostedt , Mathieu Desnoyers , Byungchul Park , "Paul E. McKenney" , Arnd Bergmann , linux-arch@vger.kernel.org, bpf , Radoslaw Burny Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 1, 2022 at 1:05 AM Peter Zijlstra wrote: > > On Mon, Feb 28, 2022 at 05:04:11PM -0800, Namhyung Kim wrote: > > The __mutex_lock_slowpath() and friends are declared as noinline and > > _RET_IP_ returns its caller as mutex_lock which is not meaningful. > > Pass the ip from mutex_lock() to have actual caller info in the trace. > > Blergh, can't you do a very limited unwind when you do the tracing > instead? 3 or 4 levels should be plenty fast and sufficient. Are you talking about getting rid of the ip from the tracepoints? Having stacktraces together is good, but it'd be nice if it provided a way to identify the lock without them too. Thanks, Namhyung