This is the mail archive of the
mailing list for the systemtap project.
Re: djprobes status
Ingo Molnar wrote:
> On Fri, 2006-09-15 at 20:50 +0200, Ingo Molnar wrote:
>> Am i missing some difficulty? The performance of probe
>> does not really matter, the critical path is probe execution.
> a third possibility would be to generate not a jump straight into the
> trampoline, but a jump to a kprobes-controlled function:
> pushw $target_IP
> this makes the inserted code 6 bytes, but gives full control to kprobes:
> you can start a probe in a non-patched function, which would start by
> first disabling preemption. It's almost as fast as the direct jump:
> modern CPUs are able to optimize such ret sequences just fine.
> at the end of the DCR trampoline you'd not jump back straight to the
> code, but you'd return-jump to another global kprobes function: which
> would re-enable preemption and which would jump back to the next
> this is all still infinitely faster than INT3 + single-stepping.
> this would make probe installation and removal quite simple, at the
> expense of some minimal runtime overhead. (10 cycles at most, on modern
Actually, the implementation will be much more complex because
we have to think about multiple probes and multiple processors.
But basically I can see the solution in your advice.
Thank you for your advice.