* Jim Keniston <jkenisto@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
