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, 21 Nov 2006 09:45:01 +0900
- Subject: Re: boosting with preemptable kernel
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <20061117235807.GB11523@urbana.css.mot.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