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: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- 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, 5 Aug 2005 11:15:24 -0400
- 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> <42F361EA.9070604@sdl.hitachi.co.jp>
* Masami Hiramatsu (hiramatu@sdl.hitachi.co.jp) wrote:
> Hi, Mathieu
>
> >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.
> >>
Yes, seems ok. I just looked at workqueue.c code, and it guarantees that the
work will be executed on the specified cpu. This is the only thing I wanted to be
sure of.
I would disable the cpu hotplug when doing this operation (have a look at
take_over_work()).
> >
> >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.
You are right.
> - It might sleep. So, we can not call it in the critical sections.
Yes, it's true : with the schedule_delayed_work_on, you don't even have to wait
for its completion : you just leave the last worker do the actual job.
> - If we want to insert a number of probes (this is usual situation in
> the module initialization), we must wait completion of all insertion.
No, this is not necessary if you design well the probe insertion steps. You
could then parallelize the insertion with an add_multiple_probes function :
- add int3 probes for all needed probes
- spawn threads or add work on each cpu
- once all the thread has runned, put the jmp or when the last work runs, put
the jmp.
> 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.
>
Workqueues seems more efficient, I agree.
>
> 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.
>
Have a good time! :)
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68