This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip v5 03/10] kprobes: Introduce kprobes jump optimization
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: rostedt at goodmis dot org
- Cc: Frederic Weisbecker <fweisbec at gmail dot com>, Ingo Molnar <mingo at elte dot hu>, 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>, "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>, Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Date: Wed, 25 Nov 2009 16:30:01 -0500
- Subject: Re: [PATCH -tip v5 03/10] kprobes: Introduce kprobes jump optimization
- References: <20091123232115.22071.71558.stgit@dhcp-100-2-132.bos.redhat.com> <20091123232141.22071.53317.stgit@dhcp-100-2-132.bos.redhat.com> <20091124024417.GA6752@nowhere> <20091124033135.GE6752@nowhere> <4B0BFCF8.4060905@redhat.com> <20091124201357.GB5071@nowhere> <4B0C492D.1060602@redhat.com> <1259183331.21397.71.camel@gandalf.stny.rr.com>
Steven Rostedt wrote:
> On Tue, 2009-11-24 at 15:59 -0500, Masami Hiramatsu wrote:
>
>>> I see...so the non-preemptible kernel requirement looks
>>> hard to workaround :-s
>>
>> It's the next challenge I think :-)
>> Even though, kprobes itself still work on preemptive kernel,
>> so we don't lose any functionality.
>
>> From kstop_machine, we could search all tasks to see if any are about to
> resume in the modified location. If there is, we could either
>
> 1) insert a normal kprobe
> 2) modify the return address of the task to jump to some trampoline to
> finish the work and return to the code spot with a direct jump.
>
> #2 is kind of nasty but seems like a fun thing to implement ;-)
Sure, anyway, a normal kprobe is already inserted, so we also can
just wait until all tasks don't resume to the spot :-)
(that's another reason why it uses delayed work for optimization.
we can try it again and again.)
And I think, that code will be shared with ksplice too.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com