From: Steven Rostedt <rostedt@goodmis.org>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-kernel@vger.kernel.org,
Indu Bhagat <indu.bhagat@oracle.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-perf-users@vger.kernel.org, Mark Brown <broonie@kernel.org>,
linux-toolchains@vger.kernel.org, Jordan Rome <jordalgo@meta.com>,
Sam James <sam@gentoo.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH v2 00/11] unwind, perf: sframe user space unwinding, deferred perf callchains
Date: Sat, 14 Sep 2024 08:12:46 -0400 [thread overview]
Message-ID: <20240914081246.1e07090c@rorschach.local.home> (raw)
In-Reply-To: <cover.1726268190.git.jpoimboe@kernel.org>
On Sat, 14 Sep 2024 01:02:02 +0200
Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> This is a new version of sframe user space unwinding + perf deferred
> callchains. Better late than never.
>
> Unfortunately I didn't get a chance to do any testing with this one yet
> as I'm rushing it out the door before GNU Cauldron starts.
> Conference-driven development ;-)
Thanks for posting this!
BTW, next time, can you also Cc linux-trace-kernel@vger.kerne.org.
>
> Plus I don't have the perf tool piece working yet so I don't have a way
> of doing end-to-end testing at the moment anyway.
>
> In other words, please don't merge this yet.
>
> Namhyung, if you're still available to write a perf tool patch which
> integrates with this, that would be great. Otherwise I could give it a
> try.
>
> Steven, let me know if this would interface ok with your anticipated
> tracing usage.
This is a very good starting point for me. A couple of notes.
I think the unwinder should have an interface itself that provides the
deferred unwinding, instead of having all the tracers to implement
their own.
The user space unwinder (regardless of sframe or not) should provide a
way to say "I want a user space stack trace for here, but don't do it
yet. Just give me a cookie and then call my callback function with the
stack and cookie before going back to user space".
That is, we should have an interface like:
typedef void (unwinder_callback_t)(struct user_space_stack *, u64 cookie);
struct unwinder_client {
struct list_head list;
unwinder_callback_t callback;
};
struct unwinder_client my_unwinder = {
.callback = mycallback;
};
register_unwinder(&my_unwinder);
Then a tracer could do this in NMI context:
/* Get the current cookie of the current task */
cookie = unwinder_get_cookie();
/* Tell the unwinder to call the callbacks */
unwinder_trigger();
/* then the tracer can save off that cookie, do a kernel stack trace
* and save the cookie with that stack trace.
*/
On return to user space, it will go the ptrace slow path and call all
registered callbacks with the cookie, regardless if it asked for it or
not.
/* Save the stack somewhere, could even allocate memory to do so */
list_for_each_entry(callback, &unwinder_callback, list) {
callback->callback(userstack, cookie);
}
update_next_cookie();
The cookie is a unique number for every entry into the kernel by all
tasks. Then it is up to the tracer's callback to know if it should save
the trace or ignore it. That is, if perf and ftrace are expecting
callbacks, but only perf triggered the callback, it should record the
cookie, and save the stack if it matches a cookie it wants. ftrace's
callback would ignore the trace, because it did not ask for a callback.
That is, the tracer will need to save off the cookie to know if its
callback needs to do something or not.
The cookie can be generated by this:
static u64 next_cookie;
u64 unwinder_get_cookie(void)
{
u64 next;
if (current->unwinder_cookie)
return current->unwinder_cookie;
next = next_cookie;
while (!try_cmpxchg64(&next_cookie, &next, next + 1))
;
next++;
/* Check for races with NMI */
if (!cmpxchg(¤t->unwinder_cookie, 0, next))
next = current->unwinder_cookie;
return next;
}
When the task goes back to user space and does all the callbacks, it
would reset the task cookie.
current->unwinder_cookie = 0;
Now the loop of callbacks should also catch if unwinder_trigger() was
called again (NMI), and may need to recall all the back traces again
with the new cookie.
That will need some thought about handling that race.
This is just an idea to start discussion.
-- Steve
next prev parent reply other threads:[~2024-09-14 12:12 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 23:02 [PATCH v2 00/11] unwind, perf: sframe user space unwinding, deferred perf callchains Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 01/11] unwind: Introduce generic user space unwinding interface Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 02/11] unwind/x86: Add HAVE_USER_UNWIND Josh Poimboeuf
2024-09-16 11:46 ` Peter Zijlstra
2024-10-20 8:09 ` Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 03/11] unwind: Introduce SFrame user space unwinding Josh Poimboeuf
2024-09-14 11:23 ` Steven Rostedt
2024-10-01 18:20 ` Indu Bhagat
2024-10-01 18:36 ` Steven Rostedt
2024-10-02 8:18 ` Florian Weimer
2024-10-02 14:05 ` Steven Rostedt
2024-10-23 13:59 ` Jens Remus
2024-10-27 17:49 ` Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 04/11] unwind/x86/64: Add HAVE_USER_UNWIND_SFRAME Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 05/11] perf/x86: Use user_unwind interface Josh Poimboeuf
2024-09-16 6:48 ` kernel test robot
2024-09-17 22:01 ` Namhyung Kim
2024-09-13 23:02 ` [PATCH v2 06/11] perf: Remove get_perf_callchain() 'init_nr' argument Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 07/11] perf: Remove get_perf_callchain() 'crosstask' argument Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 08/11] perf: Simplify get_perf_callchain() user logic Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 09/11] perf: Introduce deferred user callchains Josh Poimboeuf
2024-09-17 22:07 ` Namhyung Kim
2024-09-13 23:02 ` [PATCH v2 10/11] perf/x86: Add HAVE_PERF_CALLCHAIN_DEFERRED Josh Poimboeuf
2024-09-13 23:02 ` [PATCH v2 11/11] perf/x86: Enable SFrame unwinding for deferred user callchains Josh Poimboeuf
2024-09-14 12:12 ` Steven Rostedt [this message]
2024-09-15 11:11 ` [PATCH v2 00/11] unwind, perf: sframe user space unwinding, deferred perf callchains Josh Poimboeuf
2024-09-15 11:38 ` Steven Rostedt
2024-09-16 14:08 ` Peter Zijlstra
2024-09-16 15:39 ` Josh Poimboeuf
2024-09-16 18:15 ` Peter Zijlstra
2024-09-16 0:15 ` Mathieu Desnoyers
2024-09-16 0:33 ` Mathieu Desnoyers
2024-09-17 0:37 ` Mathieu Desnoyers
2024-09-16 22:46 ` Steven Rostedt
2024-09-17 21:58 ` Namhyung Kim
2024-09-18 5:14 ` Mathieu Desnoyers
2024-10-03 2:31 ` Steven Rostedt
2024-10-03 2:37 ` Josh Poimboeuf
2024-10-03 14:56 ` Steven Rostedt
2024-09-16 16:03 ` Steven Rostedt
2024-09-14 19:37 ` Namhyung Kim
2024-10-23 13:22 ` Jens Remus
2024-10-24 2:22 ` Steven Rostedt
2024-10-27 17:24 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240914081246.1e07090c@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=broonie@kernel.org \
--cc=indu.bhagat@oracle.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=jordalgo@meta.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sam@gentoo.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).