This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip v3&10 02/18] kprobes: Introduce generic insn_slot framework
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, Frederic Weisbecker <fweisbec at gmail dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, lkml <linux-kernel at vger dot kernel dot org>, systemtap <systemtap at sources dot redhat dot com>, DLE <dle-develop at lists dot sourceforge dot net>, Jim Keniston <jkenisto at us dot ibm dot com>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, Christoph Hellwig <hch at infradead dot org>, Steven Rostedt <rostedt at goodmis dot org>, "H. Peter Anvin" <hpa at zytor dot com>, Anders Kaseorg <andersk at ksplice dot com>, Tim Abbott <tabbott at ksplice dot com>, Andi Kleen <andi at firstfloor dot org>, Jason Baron <jbaron at redhat dot com>
- Date: Tue, 2 Mar 2010 19:32:07 -0500
- Subject: Re: [PATCH -tip v3&10 02/18] kprobes: Introduce generic insn_slot framework
- References: <20100225133342.6725.26971.stgit@localhost6.localdomain6> <20100225133358.6725.82430.stgit@localhost6.localdomain6> <20100225152130.GB12635@Krystal> <4B8C7E23.1000302@redhat.com> <4B8DAAF2.203@redhat.com>
* Masami Hiramatsu (mhiramat@redhat.com) wrote:
> Masami Hiramatsu wrote:
> > Mathieu Desnoyers wrote:
> >> * Masami Hiramatsu (mhiramat@redhat.com) wrote:
> >>> Make insn_slot framework support various size slots.
> >>> Current insn_slot just supports one-size instruction buffer slot. However,
> >>> kprobes jump optimization needs larger size buffers.
> >>
> >> OK, so you end up having one insn slot cache for kprobes and one insn
> >> slot (eventually) for the static jump patching (which needs larger
> >> instruction slots than kprobes). That seems like a good way to ensure
> >> you do not use more memory than necessary.
> >>
> >> We could possibly go even further and automatically use the right insn
> >> slot cache given the size of the instruction entry that must be added (a
> >> bit like the memory allocator which have different pools for each
> >> allocation order).
> >
> > Sure, that will be simpler interface.
> >
> >> Possibly that using the terminology of "memory pools" rather than
> >> "cache" could be a better fit too. So what this really becomes is an
> >> instruction slot allocator and garbage collector.
> >
> > Ah, right. It would be better to rename kprobe_insn_pool() :)
>
> Hmm, I tried it. And finally, I found that this doesn't help
> to simplify code... Maybe it is better to postpone it until
> another user needs this feature.
I guess it's a tradeoff between the genericity of the API you provide
and the complexity of the code that provides this API. So as you say,
maybe it's better to wait until more users appears before improving the
API.
Thanks,
Mathieu
>
> Thank you,
>
> --
> Masami Hiramatsu
> e-mail: mhiramat@redhat.com
>
--
Mathieu Desnoyers
Operating System Efficiency Consultant
EfficiOS Inc.
http://www.efficios.com