[RFC PATCH 2/3] Djprobe improvement patches (Re: Dynamic djprobe)

[Masami Hiramatsu]

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