Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



adding bpf@

On Tue, May 2, 2023 at 8:27 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Tue, 2 May 2023 12:53:53 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> > >     while (entry->nr < entry->max_stack) {
> > >             if (!valid_user_frame(fp, sizeof(frame)))
> > >                     break;
> >
> > This is broken, the sframe stuff is not NMI safe. First you need to
> > change perf to emit a forward reference to a 'next' user trace and then
> > emit the user trace on return-to-user.
> >
> > As is, perf does everything in-place from NMI context.
>
> Exactly. What I would like to see with the new sframe infrastructure is
> just a way to tell it "I want a user stack trace before going back to user
> space". Then all the work can be done in the ptrace path, where it's safe
> to memory map in the sframe section. It's not like the user space stack
> frame will change before going back to user space.
>
> This will allow for asking for the user space stack trace at any context,
> because the work will not be done until later. Of course, this may also
> require user space tooling to be updated to handle this case. Perf may
> already do that.
>
> It would also mean that even if you take multiple profiling hits in one
> system call, you will only get one user space stack trace. But that's a
> good thing. As the stack trace doesn't change, and you don't waste ring
> buffer space with unneeded duplicate stacks.

As discussed in the halls of LSF/MM2023, such lazily mapped .sframe in
approach won't work with BPF's bpf_get_stack() approach, which expects
stack trace to be grabbed and returned synchronously from NMI context.
But we can probably retrofit it into bpf_get_stackid()+STACK_TRACE BPF
map API.

Indu, please cc bpf@xxxxxxxxxxxxxxx for future revisions so we can
track and plan accordingly. Thank you!

>
> -- Steve





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux