[Bug uprobes/5509] uprobe booster thoughts

["srikar at linux dot vnet dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2009-03-13 16:09 -------
> probed instruction.  This allows us to avoid single-stepping the
> instruction copy, which should save nearly 50% of the overhead of
> a uprobe hit.
> 
> 
> The above instruction sequence takes 14 bytes: 6 bytes for the jmpq
> (always ff 25 00 00 00 00) and 8 bytes for the address.  For x86_64,
> MAX_UINSN_BYTES=16, which doesn't leave much room for the actual
> instruction copy.  We seem to have the following choices:
> a) Boost only 1-byte and 2-byte instructions.  (Ick)
> b) Make MAX_UINSN_BYTES larger.

How larger would make it feasible? Would 24 from the existing 16 bytes be good enuf?

> c) Allocate 2 SSOL slots for a boostable instruction.
> d) Allocate some big (boostable) slots and some little ones.
> 
> I prefer (b).  (c) and (d) complicate the slot allocation algorithm,
> which so far is architecture-independent.  Note that there's no
> particular reason we can't allocate more than one 4096-byte page to
> the SSOL area.

Now that we are looking at instruction analysis layer, it would be possible to
relook at option d. i.e 
A. Big slots for private and boostable instructions with instruction size
greater than 2 bytes.
B. small slots for public or boostable instructions with instruction size less
than 2 bytes.
 
How much additional complexity would this add? Would it justify the performance
gain that we get?

Though it would not solve 9826 completely, the solution for this problem could
act as a workaround for all cases where we can boost the instruction.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5509

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.