This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Preemption-safe kprobe-booster(Re: [PATCH]kprobe booster for IA64)
- From: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, SystemTAP <systemtap at sources dot redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Prasanna S Panchamukhi <prasanna at in dot ibm dot com>, Jim Keniston <jkenisto at us dot ibm dot com>
- Date: Wed, 12 Jul 2006 01:01:22 -0700
- Subject: Re: Preemption-safe kprobe-booster(Re: [PATCH]kprobe booster for IA64)
- References: <4485223C.8090109@sdl.hitachi.co.jp> <20060628190541.A13874@unix-os.sc.intel.com> <44AAF207.7090908@sdl.hitachi.co.jp> <44B4952D.9010603@hitachi.com>
- Reply-to: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
On Wed, Jul 12, 2006 at 03:22:37PM +0900, Masami Hiramatsu wrote:
> Hi, Anil
>
> > Thank you for the advice!
> > I hadn't realized it. Now, I verified it and had some ideas.
> > The problem comes from reusing the insn buffer, because
> > there might be some processes sleeping on the buffer.
> > So, I think we can avoid this problem as below:
> > First, we disable a kprobe (remove the break). Next,
> > wait until all preempted processes are waken up. And Last,
No, you can't wait until all preempted process are waken up.
Say for example, i have thread that is sleeping indefinitely
waiting on some signal or waiting on some inter-process message
or some thing like that. This thread will never ever get a chance to
run during the life-time(up time) of the system. Then your logic
of waiting until all process are waken up will not work.
> > For this purpose, I'd like to use stop_machine_run().
>
> I and Oshima-san found that stop_machine_run() was not enough
> to ensure safety. Instead of that, we focused on synchronize_sched().
You are correct, stop_machine_run() will not help you here.
> As far as we know, this function waits until all processes
> are expired. And any preempted processes can't be expired, only
> the processes who are scheduled by itself are expired.
> This means these processes already left from kprobe's slots.
> So, after that, we can release/reuse these slots safely.
I am not sure about the behavior of the synchronized_sched() for
preemptable kernels. When you say this function waits until
all processes are expired, can this mean that process'es alloted time
slot expired and hence it is scheduled out. If this is true,
then it could very well happen that when we finish executing
the original instruction in the booster buffer and just before
jumping back to original code sequence, this process time slot
can get expired and can be scheduled out and synchronize_sched()
returns and you try to reuse the buffer :(
Please confirm the behavior of synchroniz_sched() before going
ahead and implementing the code.
-Anil