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)


* 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.

> If you need to do this on each cpu to ensure they are not in intr context 
> why not use __stop_machine_run(). Take a look at kernel/cpu.c where we do 
> precicely the same thing.
>

Yes, this is exactly what we need to do.

> - 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).

Thanks for pointing it out!

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]