[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM9d7chsdfvNAX1hd3p+Jd6MvEBJd3xbe-JpE2MOBWv-vXF9DA@mail.gmail.com>
Date: Tue, 1 Mar 2022 10:25:43 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Byungchul Park <byungchul.park@....com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org,
bpf <bpf@...r.kernel.org>, Radoslaw Burny <rburny@...gle.com>
Subject: Re: [PATCH 3/4] locking/mutex: Pass proper call-site ip
On Tue, Mar 1, 2022 at 1:05 AM Peter Zijlstra <peterz@...radead.org> 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
Powered by blists - more mailing lists