boosting with preemptable kernel

[Masami Hiramatsu]

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