Will, On Tue, Jan 16, 2007 at 03:37:38PM -0500, William Cohen wrote: > Stephane Eranian wrote: > > > >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? > Yes.
> >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? > I need to double-check the logic here. I think worst case is that you are accessing the PMU state via let's say pfm_write_pmcs() and the thread is woken up. But the context switch in routine will first try to grab the context lock and that will spin until the pfm_write_pmcs() call completes. So as long as the perfmon code only touches PMU related state, we are okay I think. Anyway, I do not think we could do any much better than this without add yet another kernel mechanism. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
