[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCxM_BizulyIVcdb@gmail.com>
Date: Tue, 20 May 2025 11:35:56 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Namhyung Kim <namhyung@...nel.org>, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org,
x86@...nel.org, Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Jiri Olsa <jolsa@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCH v9 00/13] unwind_user: x86: Deferred unwinding
infrastructure
* Steven Rostedt <rostedt@...dmis.org> wrote:
> On Fri, 16 May 2025 16:39:56 -0700
> Namhyung Kim <namhyung@...nel.org> wrote:
>
> > Hi Steve,
> >
> > On Wed, May 14, 2025 at 01:27:20PM -0400, Steven Rostedt wrote:
> > > On Tue, 13 May 2025 18:34:35 -0400
> > > Steven Rostedt <rostedt@...dmis.org> wrote:
> > >
> > > > This has modifications in x86 and I would like it to go through the x86
> > > > tree. Preferably it can go into this merge window so we can focus on getting
> > > > perf and ftrace to work on top of this.
> > >
> > > I think it may be best for me to remove the two x86 specific patches, and
> > > rebuild the ftrace work on top of it. For testing, I'll just keep those two
> > > patches in my tree locally, but then I can get this moving for this merge
> > > window.
> >
> > Maybe I asked this before but I don't remember if I got the answer. :)
> > How does it handle task exits as it won't go to userspace? I guess it'll
> > lose user callstacks for exit syscalls and other termination paths.
> >
> > Similarly, it will miss user callstacks in the samples at the end of
> > profiling if the target tasks remain in the kernel (or they sleep).
> > It looks like a fundamental limitation of the deferred callchains.
> >
>
> Ah, I think I forgot about that. I believe the exit path can also be a
> faultable path. All it needs is a hook to do the exit. Is there any
> "task work" clean up on exit? I need to take a look.
Could you please not rush this facility into v6.16? It barely had any
design review so far, and I'm still not entirely sure about the
approach.
Thanks,
Ingo
Powered by blists - more mailing lists