Re: [PATCH -tip v3&10 02/18] kprobes: Introduce generic insn_slot framework

[Mathieu Desnoyers <compudj@krystal.dyndns.org>]

* 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