Stephane Eranian wrote:
Will,
On Mon, Jan 15, 2007 at 04:51:14PM -0500, William Cohen wrote:
Hi,
I have been taking a look at getting the perfmon patches working on the
Fedora
Core 7 (Raw Hide) Kernels. The Fedora Core kernels replace ptrace with
utrace
and a compatibility layer. The utrace patches remove the function
ptrace_check_attach() and the internals of ptrace are not generally
available.
The ptrace_check_attach() make sure the process's perfmon context being
modified
is stopped and the performance monitoring state is in the process state
information. The stopped process restarted is restarted in user space with a
PTRACE_CONT call. Is there anything else that is going on with using ptrace
for perfmon2?
When operating in per-thread mode, perfmon2 needs to make sure the monitored
thread is fully stopped before it must manipulate its state. Just checking
that task->state is not enough, perfmon2 needs to wait until the task is
actually OFF the CPU. It is important to note that perfmon2 does not invoke
ptrace to stop the thread, this needs to be done by the user.
So the logic in perfmon_syscalls.c does a sanity check to make sure that the
child process is actually stopped via ptrace?
That is not because we can guarantee that the thread is off the cpu, that
we are out of trouble. What would happen if the thread was woken up while
we operate on it on an SMP system? There is important property of ptrace()
which we leverage in perfmon2: ptrace maintains a ptrace parent, i.e, the
thread (process) which controls the PTRACED thread. In other words, only
one thread in the entire system may issue PTRACE commands to an already
ptraced thread. I would hope that utrace duplicates this behavior as well.
There is more information about utrace at:
http://people.redhat.com/roland/utrace/
utrace attempts remove some of the restrictions that ptrace. There could be
multiple utrace engines attached to process. There is a ptrace emulation engine
built on utrace that should emulate the behavior of ptrace. However, the ptrace
emulation engine doesn't make the internals available.
Is it always the case that the process controlling the PTRACED thread is also
issuing the perfmon commands to the PTRACED controlled thread?
-Will
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
