Re: boosting with preemptable kernel

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

Hi Quentin,

Actually, I discussed a similar idea internally with Satoshi.
And we decided the current approach is better than that, because,

Trampoline approach
- depends on the architecture. not general solution.
- increases overhead by executing trampoline code.
- is useful ONLY for booster, but is NOT useful for djprobe.

Garbage Collector (and Safety check routine)
- does NOT depends on the architecture.
- does NOT increase overhead when probing.
- is useful for not only booster but also djprobe.

Thus, I posted GC patch, and it was merged to -mm tree.
http://sources.redhat.com/ml/systemtap/2006-q4/msg00453.html

And, I know there is a weak point in the GC. It will take
a time to freeze processes. But I tried to reduce the
frequency of executing the GC by using the "dirty" flag and
some conditions. I also think we can control when it
works by introducing commit_kprobes() interface.

> (If you'd like, you can copy any or all of this post to the
> systemtap mailing list.)

Thanks, I Cc this to the SystemTap ML.

Best regards,

Quentin Barnes wrote:
> I've been working with someone else for a few weeks on an ARM
> kprobes port.  We initially started independently unaware of each
> other.  Once we found each other, we've been merging our approaches
> and efforts.
>
> In blending our two approaches, we have a possible design
> alternative that offers the speed of boosting that should work
> on under preemptable and MP kernels.  (I say "should" because we
> haven't done a live test yet, but we think it is workable.)
>
> I read your post ("[RFC][PATCH][kprobe] enabling booster on the
> preemptible kernel, take 2") to fix the current design limitation in
> boosting on preemptable and MP kernels.  I think this approach as
> laid out isn't the best approach.  It seems too expensive to solve
> the problem.  I wanted to bounce the idea our approach off you and
> see what you think of it.
>
> Instead of returning from kprobe_handler(), freeing locks, and
> restarting the instruction in the instruction slot under its
> own context, the alternate approach runs the instruction at
> kprobe_handler() invocation time before the function returns from
> the exception.  That way preemption is still held disabled and
> the resource lock is still held on the slot when the instruction
> runs.  To run the instruction before returning requires enough of
> the context from the "regs" parameter be restored by a trampoline,
> the instruction in the instruction slot to jumped to and then back
> to another trampoline that saves any updates to the register state
> back into "regs".  It's a very simple design that solves the problem
> cleanly by eliminating any races since no locks (preemption or
> instruction slot) are released in the interm.  The only drawback I
> see is that it requires some assembly in the architecture dependent
> implementation code for the two trampolines.
>
> Has an approach like the above this been discussed?  Is there a
> reason to prefer the garbage collection approach over an approach
> like the above?
>
> Now the above approach doesn't handle all instructions including
> those that read or write the PC.  Those are handled by another very
> similar approach except it simulates execution of the instruction
> rather than vectoring through the trampolines.
>
> (If you'd like, you can copy any or all of this post to the
> systemtap mailing list.)
>
> Quentin Barnes
>
>


-- 
Masami HIRAMATSU
Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com