This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: boosting with preemptable kernel
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Quentin Barnes <qbarnes at urbana dot css dot mot dot com>
- Cc: 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>, SystemTAP <systemtap at sources dot redhat dot com>
- Date: Tue, 30 Jan 2007 14:05:41 +0900
- Subject: Re: boosting with preemptable kernel
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <20061117235807.GB11523@urbana.css.mot.com> <45624C0D.3030007@hitachi.com> <20070103223912.GA13162@urbana.css.mot.com> <45A99FC3.5050805@hitachi.com> <20070127063742.GA18383@urbana.css.mot.com>
Hi Quentin,
Quentin Barnes wrote:
>> Djprobe has to rewrite multiple instructions on i386 (CISC), because
>> the size of the long jump instruction is bigger than many instructions.
>> Before rewriting those instructions, we must ensure no other processes
>> running/sleeping on the target instructions which will be rewritten by
>> the long jump. This case can not be helped by the trampoline routine.
>
> Yes, that's a very, very messy problem on the x86. Up to five(?)
> instructions could be overwritten by the long jump instruction.
>
> I'm still not sure though I see why a trampoline approach wouldn't
> work for x86. It would just have to iterate the trampoline up to
> five times. But I still don't have the model clear enough in my
> head yet. Maybe it will become clearer over time.
Similar idea had discussed with Karim on the thread below:
http://sourceware.org/ml/systemtap/2006-q3/msg00725.html
> As long as the kernel text address space stays under 32MB, an
> ARM djprobe implementation would be a one-for-one instruction
> replacement.
Unfortunately, the djprobe allocates its stub buffer from the
module area. Is it included in the 32MB area on ARM?
> I'm still absorbing the djprobes explanation (djprobe-20051031.txt)
> and perusing the patch you sent out Nov 21. Sorry if the following
> question has already been discussed. If it has, just point me to
> it. Is there a reason djprobes needs its own, separate interface?
> Could it just use the kprobes registration service and have the
> kprobes code decide whether to implement a given probe as a kprobe
> with an exception or djprobe with a direct jump? Or is this a long
> term goal after shaking out the djprobes model?
Before I sent the latest patch, we are discussed that.
The patch which I sent Nov 21, integrated the djprobe's interface
into kprobe's interface. If user sets the length of the instructions
(which will be replaced by a long jump) to the length member of the
kprobe data structure, that kprobe will be optimized (become a
djprobe) after invoking commit_kprobes().
Best regards,
--
Masami HIRAMATSU
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com