On Sun, 22 Feb 2015, Benjamin Moody wrote: > On 2/21/15, Vince Weaver <[email protected]> wrote: > > On Sat, 21 Feb 2015, Benjamin Moody wrote: > > > > > >> there are grandchild processes involved. (And I can't help thinking > >> the first version is a lot more elegant!) Does the kernel somehow get > >> confused because enable_on_exec is set and the original process hasn't > >> actually exec'ed anything? > > > > Have you tried enabling the "inherit_stat" flag to see if that helps? > > That does seem to help for the simple case I posted. It doesn't work > in all cases, though. I'll have to experiment a bit to find a simple > example. > > My impression was that the inherit_stat bit shouldn't matter if we are > only interested in aggregate event counts, as opposed to counting > events per thread (found a ML thread about this a while ago but I > can't find it right now.) Please correct me if I'm wrong. In any > case, though, the perf tool doesn't use that bit.
If you can come up with a coherent explanation of what the inherit_stat bit does I'll be glad to add it to the manpage. >From what I vaguely understand it has to do with when a read() happens whether you bother to iterate all children and get updated event counts from them rather than just using the value from the last time they context switched. I probably have that all mixed up though. It's true perf doesn't use that bit, but I thought we already established that your code doesn't start a process the same way that perf does. I am interesting in seeing if we can get to the bottom of this issue, as I've had users report issues when trying to measure OpenMP programs, though I'm not sure if they're seeing the exact same problem. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
