This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]kprobe booster for IA64

Hi, Anil

Keshavamurthy Anil S wrote:
> pre_preempt_count will always be one here, since 
> notify_die()->atomic_notifier_call_chain()->read_rcu_lock()->preeempt_disable(). 
> So currently you might be preparing for boosting even for 
> preemptable code path. Can you verify this.

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,
we release its insn buffer to reuse. Then, it will be safe.
Because there is no process slept on the buffer.

For this purpose, I'd like to use stop_machine_run().
However we can't execute it each releasing time because
it is very costly.
I think we can resolve it by using garbage collector.

I describe my idea below:
The kprobe frees its insn slot(buffer) after disable it.
Thus, when an insn slot is freed, it will be just marked as
a garbage. And when get_insn_slot() can't find any free slot,
it will call the garbage collector to try to refill free slots.
And the garbage collector uses stop_machine_run() to ensure safety.
What do you think about this idea?

Best regards,

2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
(New)E-mail: (This is available from 8th, Jul)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]