Re: [LSF/MM/BPF TOPIC] faster uprobes

[Jiri Olsa <olsajiri@gmail.com>]

On Thu, Feb 29, 2024 at 04:25:17PM -0800, Andrii Nakryiko wrote:
> On Thu, Feb 29, 2024 at 6:39 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > One of uprobe pain points is having slow execution that involves
> > two traps in worst case scenario or single trap if the original
> > instruction can be emulated. For return uprobes there's one extra
> > trap on top of that.
> >
> > My current idea on how to make this faster is to follow the optimized
> > kprobes and replace the normal uprobe trap instruction with jump to
> > user space trampoline that:
> >
> >   - executes syscall to call uprobe consumers callbacks
> 
> Did you get a chance to measure relative performance of syscall vs
> int3 interrupt handling? If not, do you think you'll be able to get
> some numbers by the time the conference starts? This should inform the
> decision whether it even makes sense to go through all the trouble.

right, will do that

jirka

> 
> >   - executes original instructions
> >   - jumps back to continue with the original code
> >
> > There are of course corner cases where above will have trouble or
> > won't work completely, like:
> >
> >   - executing original instructions in the trampoline is tricky wrt
> >     rip relative addressing
> >
> >   - some instructions we can't move to trampoline at all
> >
> >   - the uprobe address is on page boundary so the jump instruction to
> >     trampoline would span across 2 pages, hence the page replace won't
> >     be atomic, which might cause issues
> >
> >   - ... ? many others I'm sure
> >
> > Still with all the limitations I think we could be able to speed up
> > some amount of the uprobes, which seems worth doing.
> >
> > I'd like to have the discussion on the topic and get some agreement
> > or directions on how this should be done.