Improvement for post-handler only case in kprobes

Improvement for post-handler only case in kprobes

[Jun Koi]

Hello,

I am reviewing the code of kprobes, and have an idea. Is there any
case we need only post-handler for a probe, but not pre-handler? If
that is the case, i think it is possible to improve the performance in
the similar approach with kprobe-booster.

For the moment, if the probe has only post-handler, we need to switch
out 2 times:
1. When the probe is hit, we switch out with BreakPoint instruction.
The processor is the put into Single-step mode.
2. After single-step, we switch out again.

In case we only has post-handler (NOT pre-handler), we can eliminate
the single-mode step in the following way:
- Still put BreakPoint at the registered address.
- After the single-step, remove the old BreakPoint and put it at the
current EIP (this is the place we switch out with single-step). Next
time, we only need to handle the breakpoint, as it is hit right after
the "original" breakpoint. Hence we dont need to get into the
single-step mode any more. Of course this improves the performance.

Of course if we analyze the instruction at the original address when
registering the probe, we can find the next instruction. But with the
above scheme we dont need to do that, with the price of 1 single-step
for the first time the probe is hit.

Any comment? Is this worth implementing?

Regards,
Jun

Re: Improvement for post-handler only case in kprobes

[Jun Koi]

On 10/31/06, Stone, Joshua I <joshua.i.stone@intel.com> wrote:
> On Sunday, October 29, 2006 6:02 AM, Jun Koi wrote:
> > [...]
> > In case we only has post-handler (NOT pre-handler), we can eliminate
> > the single-mode step in the following way:
> > - Still put BreakPoint at the registered address.
> > - After the single-step, remove the old BreakPoint and put it at the
> > current EIP (this is the place we switch out with single-step). Next
> > time, we only need to handle the breakpoint, as it is hit right after
> > the "original" breakpoint. Hence we dont need to get into the
> > single-step mode any more. Of course this improves the performance.
>
> So you're basically suggesting to turn a post-handler on a instruction
> into a pre-handler on the following instruction?

Yes, that is my idea.

>
> This is equivalent only if you can guarantee that the two instructions
> will always execute together.  Thus the first instruction cannot be a
> control instruction (branch, jump, etc.), and the second cannot be the
> target of any control instruction.  You would have to do full
> basic-block analysis to guarantee this condition.

Yes, unfortunately we cannot do it without some price paying.

>
> In any case, I don't think you'll save anything, because whatever
> instruction is replaced with a breakpoint still needs to be executed.
> This happens out-of-line and single-stepped.

What we gain is performance improvement, because we no longer have to
single-step any more (in case we successfully boost with boostable
instruction). Meanwhile in the current approach, we always have to do
single-step for post-handler.


Thank you,
Jun

>
>
> Josh
>

RE: Improvement for post-handler only case in kprobes

[Stone, Joshua I]

On Sunday, October 29, 2006 6:02 AM, Jun Koi wrote:
> [...]
> In case we only has post-handler (NOT pre-handler), we can eliminate
> the single-mode step in the following way:
> - Still put BreakPoint at the registered address.
> - After the single-step, remove the old BreakPoint and put it at the
> current EIP (this is the place we switch out with single-step). Next
> time, we only need to handle the breakpoint, as it is hit right after
> the "original" breakpoint. Hence we dont need to get into the
> single-step mode any more. Of course this improves the performance.

So you're basically suggesting to turn a post-handler on a instruction
into a pre-handler on the following instruction?

This is equivalent only if you can guarantee that the two instructions
will always execute together.  Thus the first instruction cannot be a
control instruction (branch, jump, etc.), and the second cannot be the
target of any control instruction.  You would have to do full
basic-block analysis to guarantee this condition.

In any case, I don't think you'll save anything, because whatever
instruction is replaced with a breakpoint still needs to be executed.
This happens out-of-line and single-stepped.


Josh