* Jim Keniston <jkeni...@us.ibm.com> wrote:
> > > As previously discussed, boosting would also get rid of the single-step
> > > trap for most instructions.
> >
> > Boosting is not in the uprobes patch-set you submitted. Even with it
> > present it wont get rid of the initial INT3. So basically _best-case_
> > (with boosting) XOL-uprobes could roughly break even with a pure emulator
> > approach ...
> >
> > That's a big and fundamental difference.
>
> To be fair, wrt uprobes, emulation and boosting are both in the same state:
> pretty well understood, but not yet implemented.
So, to sum it up: utrace XOL, which is rather complex already, needs even more
complexity (which is not yet implemented) than the much simpler common-case
emulator approach i outlined, just to break even with the performance of the
much simpler approach.
And you've been justifying the complexity of XOL with its performance
advantages.
See why i'm unimpressed by that argument?
[ Note, i'm not dismissing it entirely, the complexity of XOL _might_ be fine
in the future if it brings us real advantages: for example if it avoids
_ALL_ kernel entries.
That can be done too, by using the jump-probe technique in user-space. (the
closest anyone came to proposing this was Avi with the user-space INT3 hack
- but we can do better than that via the jprobes technique.) At that point
the advantage of having a pure user-space callback technique combined with
the advantages of having near full instruction coverage might tip the
balance. There are other complexities to handle in that case though, like
buffering and more. ]
But right now we are nowhere near that stage, and i dont see the path towards
that either. So i'd much rather see something simpler and get on with these
IMHO unimportant performance details to the IMO much more important high level
interface and high level tooling details.
When we merged kprobes ~10 years ago we made the (rather bad) mistake of
merging a raw, opaque facility and leaving 'the rest' up to some other entity.
IBM kprobes hackers vanished the day the original kprobes code went upstream
and the high level entity never truly materialized in-kernel, for nearly a
decade!
With uprobes we should learn from that painful lesson and bring in the high
level users of uprobes via 'perf probe' (or any other real user) straight
away.
Complexity is easy to increase when usage is increasing, it's near impossible
to reduce when usage is not there. (and it's rather hard to reduce even with
increasing usage - especially of aspects of the complexity leak out to
user-space ABIs - which danger XOL has written all over it.)
So the request is simple to sum up: please reduce complexity of the initial
submission and increase all around utility.
Thanks,
Ingo
