This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC PATCH 2/3] Djprobe improvement patches (Re: Dynamic djprobe)
- From: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- To: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- Cc: Ashok Raj <ashok dot raj at intel dot com>, systemtap at sources dot redhat dot com, "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, Roland McGrath <roland at redhat dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Andi Kleen <ak at muc dot de>, michel dot dagenais at polymtl dot ca, "Frank Ch. Eigler" <fche at redhat dot com>, Karim Yaghmour <karim at opersys dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Yumiko Sugita <sugita at sdl dot hitachi dot co dot jp>
- Date: Fri, 05 Aug 2005 21:56:10 +0900
- Subject: Re: [RFC PATCH 2/3] Djprobe improvement patches (Re: Dynamic djprobe)
- References: <20050804175433.GA23544@Krystal> <20050804125933.A17107@unix-os.sc.intel.com> <20050805015549.GA8644@Krystal>
Hi, Mathieu
Mathieu Desnoyers wrote:
* Ashok Raj (ashok.raj@intel.com) wrote:
On Thu, Aug 04, 2005 at 10:54:33AM -0700, Mathieu Desnoyers wrote:
I dont have enough context, just joined the list. Looking through the list
iam guessing its one of the two below that you require.
if this is one-shot, could you use something like schedule_delayed_work_on()
Yes, it could do the job, but using the timer to do this doesn't seem very clean
to me. Even if this operation can be done very slowly.
Hmm, would you worry about execution context? As far as I know, a work
is always executed by the kevent kernel thread. Timer just pushes a work
into workqueue.
- You pass in a func/preferred cpu (if none, we pick one for you)
- your function is called when all cpus have performed local_irq_disable,
disable_preempt()
- now your function is called to do this atomically.
I just looked at __stop_machine_run : this is exactly the sequence of
kthread_create - kthread_bind - wake_up_process I was talking about, plus a
wait_for_completion. It seems like the clean way to do it. This function seems
to take care of the CPU unplug too (in the stop_machine_run).
I also look at kernel/stop_machine.c. I think stop_machine_run() has
some latency issues;
- It must create threads for each CPU. If we have 32 way machine, it
must create 32 threads. It is not so light processing.
- It might sleep. So, we can not call it in the critical sections.
- If we want to insert a number of probes (this is usual situation in
the module initialization), we must wait completion of all insertion.
What do you think about these issues?
I already developed two versions of djprobe patches. One uses
stop_machine_run(), and the other one uses workqueue. I attach these
patches in following mails.
By the way, I will have the summer vacation of 10 days from tomorrow.
So, I'm very sorry that I won't be able to reply your mail.
Best regards,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp