This is the mail archive of the systemtap@sourceware.org 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 2/5][Djprobe]Djprobe Coexist with Kprobes


Hi, Anil

Keshavamurthy Anil S wrote:
> On Thu, Oct 13, 2005 at 07:12:09PM +0900, Masami Hiramatsu wrote:

>>>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?
>

I think it will work. And I wrote it as a pseudo-code here.
Does this fit your idea?

---
register_djprobe()
{
	down(&djprobe_mutex); /* avoid deadlock */

	instance = create_instance();
	register_kprobe(&instance->kp);

	/* schedule check routine */
	for_each_other_cpu()
		schedule_work(per_cpu_works);
	flush_scheduled_work(); /* might sleep */

	arch_install_instance(instance);

	up(&djprobe_mutex);
}

unregister_djprobe()
{
	down(&djprobe_mutex); /* avoid deadlock */

	arch_uninstall_instance(instance);

	/* schedule check routine */
	for_each_other_cpu()
		schedule_work(per_cpu_works);
	flush_scheduled_work(); /* might sleep */

	unregister_kprobe(&instance->kp);
	release_instance(instance);

	up(&djprobe_mutex);
}
---

Of course, this code would not block other processes, and not
allocate any temporary works.
But, if we use flush_scheduled_work(), register/unregister_djprobe()
might sleep. In other words, those functions are no longer atomic.
So, it would take a long time to register/unregister some probes
at a time.
I'm concerned about this point. What do you think about that?

Thanks,

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp


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