Andrej, Thanks for sharing your experience. Some comments below.
On Sun, Sep 14, 2008 at 10:35 AM, Andrej van der Zee <[EMAIL PROTECTED]> wrote: > Hi, > > I have been trying to incorporate perfmon2 with libpfm into an existing > open-source project in C and I want to share my experiences as an end-user. > I am fairly new to perfmon2 and libpfm, so forgive me if I state anything > incorrect. > > Well, for self-monitoring it all works very well and it is straightforward > to implement / add to existing projects. Moreover, there are numerous > examples that illustrate many usages. > > But, the problems started when I wanted to follow forks(). Even though I am > able to do self-monitoring, I have to attach from a monitoring process with > ptrace(). This is quite a lot of overhead for applications that have many > worker threads that need to be monitored individualy, slows down performance > because of ptrace() and is not easy to add to an existing project. In my > opinion, it would be very useful to add an option to libpfm that makes child > processes inherit the context and add to the counters. Then, in cases > similar to mine, attaching with ptrace() would be unnecasary. > The choice of not automatically following across fork was made on purpose. Although, it may work in simple situations where you are just counting, like you are, there are some difficulties when you are sampling. Furthermore, users may not want to measure in all children. They may want to know which child they are actually monitoring. They may not want aggregation, or if so they may want to know from how many children. All those things go away if you systematically follow across fork/pthread_create. It is always best to leave that control to the controller of the session which may also be the consumer of the produced data. When sampling, you want to know the identity of the process you are collecting samples from because you most likely need to correlate sample addresses to functions names. So again, the controller needs to intervene to gather enough information to be able to correlate either on the fly or afterwards. The constraints you mention with ptrace() come from the fact that it was not designed to do this. Yet, this is the only mechanism available today to stop/restart another process or thread. There is overhead in coding it, there is also in calling ptrace(). However, it is expected that attach/detach are not in the critical path of monitoring. Hopefully, you monitor for period of times that are longer than the time it takes to attach and detach. And yes, there are nasty side effects, e.g, signals, in keeping a process under ptrace. But note that you DO NOT NEED to keep the process under ptrace once you've started monitoring, I think the task_smpl.c example show this. And as I said earlier, I am hopeful utrace will be included in the kernel soon, so we won't have to rely on ptrace, and the nasty side effects will go away. Thanks. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
