This is the mail archive of the 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

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.

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.


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