stephane eranian wrote: > Maynard, > > Thanks for the patch. I don't know the utrace API but I have a few comments > about your patch: > > - it looks like ptrace remains available to users even though utrace > is in the kernel. > I am assuming ptrace is then built on top of utrace. > > - the current perfmon API requires that the user issue > ptrace(ATTACH) before allowing > access to the perfmon context from another thread. This is because > certain perfmon > actions require modifying the PMU and/or machine state of the other > thread. > > - The monitored thread must be off any CPU completely before we can > proceed with > a perfmon access. Although there is locking around the perfmon > context and lock > is grabbed when context switching, there are certain > architectures, e.g., Itanium, > where perfmon call need to modifying state beyond the pure PMU > registers, e.g., > a processor status register which is not protected by any perfmon lock. > > - The thread must remain off any CPU during the entire duration of > the perfmon access. > It should not be possible to wake up the while in the middle of a > perfmon syscall. That > is one property of ptrace we heavily leverage. Only the ptracing > parent can wake the > thread. According to Documentation/utrace.txt, "as long as any engine asserts the QUIESCE action flag, the thread will not resume running in user mode". > > - To maintain compatibility with existing perfmon applications using > ptrace, you have to > fail is you notice the thread is not in a quiescent state or is > not going to. It would be My patch has a "FIXME" in it right now where I go through some steps to quiesce the task if it isn't already -- even though it *really* should be, since the user should have called ptrace(PTRACE_ATTACH), which should be quiescing the task. Maybe you'd rather fail here instead. Feel free to make such a change in the patch if that seems more appropriate to you.
> nice if the kernel could stop the thread on behalf of the caller. > This is not very easy to > do with ptrace, maybe with utrace it is. I am willing to revisit > this as I think it would be > nicer to user. Ptrace has other undesirable side effects, such as > redirecting signals. > > - Suppose I would like to add your patch to the existing tree, what > CONFIG_XXX should > I use to make this code compile only of utrace is enabled? There is a CONFIG_UTRACE option. Regards, -Maynard > > > Thanks. > > On Fri, Mar 28, 2008 at 10:04 PM, Maynard Johnson <[EMAIL PROTECTED]> wrote: >> Hi, Stephane, >> As you may recall, about a month ago, I posted a question to the utrace >> mailing list, asking about a compile failure I was seeing in >> perfmon/perfmon_syscalls.c because it's trying to use the function >> ptrace_check_attach (removed by the utrace patch). I've attached a >> patch that we've been using that fixes the compile failure and seems to >> functionally work. Feel free to use it if you wish. Please let me know >> if it seems correct to you. >> >> Thanks. >> >> Maynard Johnson >> IBM POWER Toolchain Team >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> _______________________________________________ >> perfmon2-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >> >> ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ perfmon2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
