Hi Balbir,



On Friday 16 December 2016 08:16 PM, Balbir Singh wrote:

On 15/12/16 03:18, Anju T Sudhakar wrote:

quoted

This is the V2 patchset of the kprobes jump optimization
(a.k.a OPTPROBES)for powerpc. Kprobe being an inevitable tool
for kernel developers, enhancing the performance of kprobe has
got much importance.

Currently kprobes inserts a trap instruction to probe a running kernel.
Jump optimization allows kprobes to replace the trap with a branch,
reducing the probe overhead drastically.

In this series, conditional branch instructions are not considered for
optimization as they have to be assessed carefully in SMP systems.

The kprobe placed on the kretprobe_trampoline during boot time, is also
optimized in this series. Patch 4/4 furnishes this.

The first two patches can go independently of the series. The helper
functions in these patches are invoked in patch 3/4.

Performance:
============
An optimized kprobe in powerpc is 1.05 to 4.7 times faster than a kprobe.
  
Example:
  
Placed a probe at an offset 0x50 in _do_fork().
*Time Diff here is, difference in time before hitting the probe and
after the probed instruction. mftb() is employed in kernel/fork.c for
this purpose.
  
# echo 0 > /proc/sys/debug/kprobes-optimization
Kprobes globally unoptimized
  [  233.607120] Time Diff = 0x1f0
  [  233.608273] Time Diff = 0x1ee
  [  233.609228] Time Diff = 0x203
  [  233.610400] Time Diff = 0x1ec
  [  233.611335] Time Diff = 0x200
  [  233.612552] Time Diff = 0x1f0
  [  233.613386] Time Diff = 0x1ee
  [  233.614547] Time Diff = 0x212
  [  233.615570] Time Diff = 0x206
  [  233.616819] Time Diff = 0x1f3
  [  233.617773] Time Diff = 0x1ec
  [  233.618944] Time Diff = 0x1fb
  [  233.619879] Time Diff = 0x1f0
  [  233.621066] Time Diff = 0x1f9
  [  233.621999] Time Diff = 0x283
  [  233.623281] Time Diff = 0x24d
  [  233.624172] Time Diff = 0x1ea
  [  233.625381] Time Diff = 0x1f0
  [  233.626358] Time Diff = 0x200
  [  233.627572] Time Diff = 0x1ed
  
# echo 1 > /proc/sys/debug/kprobes-optimization
Kprobes globally optimized
  [   70.797075] Time Diff = 0x103
  [   70.799102] Time Diff = 0x181
  [   70.801861] Time Diff = 0x15e
  [   70.803466] Time Diff = 0xf0
  [   70.804348] Time Diff = 0xd0
  [   70.805653] Time Diff = 0xad
  [   70.806477] Time Diff = 0xe0
  [   70.807725] Time Diff = 0xbe
  [   70.808541] Time Diff = 0xc3
  [   70.810191] Time Diff = 0xc7
  [   70.811007] Time Diff = 0xc0
  [   70.812629] Time Diff = 0xc0
  [   70.813640] Time Diff = 0xda
  [   70.814915] Time Diff = 0xbb
  [   70.815726] Time Diff = 0xc4
  [   70.816955] Time Diff = 0xc0
  [   70.817778] Time Diff = 0xcd
  [   70.818999] Time Diff = 0xcd
  [   70.820099] Time Diff = 0xcb
  [   70.821333] Time Diff = 0xf0

Implementation:
===================
  
The trap instruction is replaced by a branch to a detour buffer. To address
the limitation of branch instruction in power architecture, detour buffer
slot is allocated from a reserved area . This will ensure that the branch
is within ± 32 MB range. The current kprobes insn caches allocate memory
area for insn slots with module_alloc(). This will always be beyond
± 32MB range.
  

The paragraph is a little confusing. We need the detour buffer to be within
+-32 MB, but then you say we always get memory from module_alloc() beyond
32MB.

The last two lines in the paragraph talks about the*current 
*method**which the regular kprobe uses
for allocating instruction slot. So in our case, we can't use 
module_alloc() since there is no guarantee that the slot allocated will 
be within +/- 32MB range.

quoted

The detour buffer contains a call to optimized_callback() which in turn
call the pre_handler(). Once the pre-handler is run, the original
instruction is emulated from the detour buffer itself. Also the detour
buffer is equipped with a branch back to the normal work flow after the
probed instruction is emulated.

Does the branch itself use registers that need to be saved? I presume
we are going to rely on the +-32MB, what are the guarantees of success
of such a mechanism?

For branching back to the next instruction, after the execution of the 
kprobe's pre-handler,
we place the branch instruction in the detour buffer itself. Hence we 
don't have to clobber any registers
after restoring them.
Before optimizing the kprobe we make sure that , 'branch to detour 
buffer' and 'branch back from detour buffer' is within +/- 32MB range. 
This ensures the working of optimized kprobe.


Thanks ,
Anju

Balbir Singh.