This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Patch 2/5][Djprobe]Djprobe Coexist with Kprobes
- From: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
- To: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- Cc: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>, systemtap at sources dot redhat dot com, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, sugita at sdl dot hitachi dot co dot jp
- Date: Tue, 18 Oct 2005 20:57:41 -0700
- Subject: Re: [Patch 2/5][Djprobe]Djprobe Coexist with Kprobes
- References: <433BE533.9080501@sdl.hitachi.co.jp> <20051003162917.A16966@unix-os.sc.intel.com> <434490F0.3030400@sdl.hitachi.co.jp> <20051006125717.A18501@unix-os.sc.intel.com> <434E32F9.2000509@sdl.hitachi.co.jp>
- Reply-to: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
On Thu, Oct 13, 2005 at 07:12:09PM +0900, Masami Hiramatsu wrote:
> Hi, Anil
>
>
>
> >
> > Also, I see the same linear search happening inside work_check_djprobe_instance().
> > As I understand you are scheduling this function on all the cpus and inside this
> > function you are doing a linear search for djprobe instances that too holding
> > a spin lock and thus making other thread executing this function on different
> cpus to
> > wait untill you finish serial search on this cpu. Hence my suggestion to look into
> > optimizing this search.
>
> OK, that is a problem. I have an idea of "per-probe work"s to solve it.
> This will allocate a lot of works and insert it into the workqueues on each cpu.
> Is this acceptable?
How about calling flush_scheduled_work(). Will this work?
Cheers,
Anil