This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH 2/5][djprobe] djprobe core patch
- From: Ingo Molnar <mingo at redhat dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: Keshavamurthy at bambi dot jf dot intel dot com, Anil S <anil dot s dot keshavamurthy at intel dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Prasanna S Panchamukhi <prasanna at in dot ibm dot com>, SystemTAP <systemtap at sources dot redhat 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>
- Date: Mon, 30 Oct 2006 15:10:43 +0100
- Subject: Re: [PATCH 2/5][djprobe] djprobe core patch
- References: <45338593.6090207@hitachi.com> <45373F28.1070305@hitachi.com> <20061027233941.GB10018@bambi.jf.intel.com> <454606E0.3050703@hitachi.com>
On Mon, 2006-10-30 at 23:06 +0900, Masami Hiramatsu wrote:
> 1) I thought that should be waste of memory. As you can see,
> the djprobe structure doesn't have its kprobe nor instruction
> buffer, because it is just an interface structure. Instead of
> that, it has an pointer to the djprobe_instance structure which
> is true instance of the djprobe. This "instance" has the kprobe
> structure and instruction buffer. So, I could keep the djprobe
> structure small.
> 2) The other reason is from difference of the usage between djprobe
> and kprobe. Kprobe users have to ensure that the target address
> points to the 1st byte of instruction. On the other hand, djprobe
> users additionally have to count the length of the target
> instructions, and ensure those instructions are relocatable.
>
> Therefore, I provided those special interfaces.
>
> If you never mind that the jump-based-kprobe needs two
> kprobe structures per one probe point (one is for the interface,
> another is for the instance -- for deferred releasing), I can
> integrate these interfaces.
I dont think memory overhead is a big issue - API compatibility is
important and it will also speed up the adoption of djprobes.
could the size restriction of djprobes be relaxed by it doing a
deassembly of the instruction? (only to figure out the size of the
instruction)
basically, i think the best model would be to make djprobes a
transparent speedup of kprobes.
Ingo