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: [RFC PATCH 2/3] Djprobe improvement patches (Re: Dynamic djprobe)


* 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 


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