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: djprobes status


Ingo Molnar wrote:
> On Fri, 2006-09-15 at 14:43 -0400, Satoshi Oshima wrote:
>> For djprobe, it is unavailable to take such a strategy, because 
>> there is no space to put preempt_enable() after jmp instruction
>> in the buffer or in original code.
>>
> thanks for the explanation.
> 
> I'm wondering - why dont we fix up the IP of all preempted tasks back to
> the restored [formerly destroyed] range?
> 
> Similarly, a mirror problem exists when inserting a probe: the matching
> IPs of currently preempted tasks have to be fixed up too to point to the
> right offset in the DCR buffer.

Yes, true. So djprobes put int3 first and wait for hit of it for safety.
After that replace int3 with jmp instruction.

> Am i missing some difficulty? The performance of probe insertion/removal
> does not really matter, the critical path is probe execution.
> 
> another method to solve this would be to force all tasks in the system
> to 'gather', then do the modification and then 'release' them. That is
> precisely what sw-suspend/resume already does, and we could reuse that
> existing infrastructure: take a look at kernel/power/process.c's
> freeze_processes() and thaw_processes() functions. It takes care of
> kernel threads too.

We proposed such an idea, but tons of disagreement had come at that
time;-) If you support the plan, it is worth to try it again.


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