On 05/03/2010 01:46 AM, stephane eranian wrote: > On Sat, May 1, 2010 at 3:37 AM, Corey Ashford > <cjash...@linux.vnet.ibm.com> wrote: >> Hi Stephane, >> >> When I posted the patch, I hadn't really tested it much. Now that I'm >> testing it, I'm seeing some very strange behavior. After I worked through a >> number of oversights I had made, I have come to this point where I find that >> grouping and "enable_on_exec" don't appear to work together. At first I >> thought it was my code, but I reverted back to the stock code for "task", >> and am seeing this on Linux kernel version 2.6.33.3: >> >> % ./task -e PM_RUN_CYC,PM_INST_CMPL sleep 3 >> 438,780 PM_RUN_CYC (963,728 : 963,728) >> 139,211 PM_INST_CMPL (963,728 : 963,728) >> >> This looks correct, but if I add the -g switch: >> >> % ./task -g -e PM_RUN_CYC,PM_INST_CMPL sleep 3 >> task: could not read event0 ret=32<<<<<<<< Notice this >> 437,055 PM_RUN_CYC (930,392 : 930,392) >> 0 PM_INST_CMPL (930,392 : 930,392) >> >> Does this look familiar to you? >> > > Yes. I get the same on x86. This is a problem I reported on LKML a couple of > weeks ago. > > There is a serious bug with the management of groups. The issue is > related to group > and attach/detach. In the case of the task example, you read the > counts once the monitored > task has died, i.e., events are detached. It turns out that group > reading, i.e, a single read to > extract all the values of a group, is broken. It works fine as long as > the events are attached > to the task, but it fails when they are detached. After detachment, > all you can read out via > the leader's fd is the leader's count. To read the "slave" counts, you > have to use their file > descriptors. This is a bug. If events are created as a group then they > must be managed as > a group all along, at least as long as the leader exists. > > I have not heard back from LKML since I posted the problem.
Sorry, I missed this reply earlier. I made a cutdown of "task" and posted it up on LKML. Perhaps someone will be able to take a look and find a good fix. In the meantime, the patch for "task" I posted to the perfmon2 mailing list yesterday contains a work-around for this problem - it uses PERF_FORMAT_GROUP only optionally. - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR cjash...@us.ibm.com ------------------------------------------------------------------------------ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel