This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 0/4][kprobe](djprobe) Direct jump optimized kprobes
- From: Ingo Molnar <mingo at redhat dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, SystemTAP <systemtap at sources dot redhat dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Prasanna S Panchamukhi <prasanna at in dot ibm dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Jim Keniston <jkenisto at us dot ibm dot com>, Martin Bligh <mbligh at google dot com>, Greg Kroah-Hartman <gregkh at suse dot de>
- Date: Mon, 27 Nov 2006 13:59:48 +0100
- Subject: Re: [RFC][PATCH 0/4][kprobe](djprobe) Direct jump optimized kprobes
- References: <4562A150.2030606@hitachi.com>
On Tue, 2006-11-21 at 15:48 +0900, Masami Hiramatsu wrote:
> Hi Anil and Ingo,
>
> I integrated the essence of the djprobe into kprobes. For this
> purpose, I introduced the length member in the kprobe structure.
>
> If you'd like to use it, specify the length of the instructions
> which will be replaced by a jump code to that length member.
> (Of cause, you also have to check whether the instructions are
> relocatable and don't include any jump target.)
cool stuff!
I'm wondering whether it could be made a 100% transparent speedup to
kprobes: how hard would it be to do a simplified disassembly of the
target address to automate the 'this kprobe can safely be turned into a
djprobe transparently' step, and hence to make this change completely
invisible to user-space utilities? Userspace would have to do something
like this anyway (unless i'm missing something), correct?
It might also be useful to implement some sort of query functionality,
to enable userspace to see which probes are sped up and which are not.
This could be a list of all probe points in /sys or /proc or /debugfs -
or a syscall extension - whichever fits the purpose best.
also, it would be nice to submit to this Andrew for -mm inclusion.
Ingo