> 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.
Sorry, I can't make sense of it either. This must be the thread I was thinking of (I see you're the original author): http://www.mail-archive.com/[email protected]/msg01014.html > 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. True. But if inherit_stat is necessary in order to get accurate results in some circumstances, then perhaps perf should be using it as well. I'm starting to see where the problem might be with my original understanding of the event counter system. I was thinking of an event counter as a thing that could be turned on and off on a per-process basis, so it made sense to think that 'enable_on_exec' would enable the counter for only the processes that were descended from the one that did the exec. But that's not really the right model, is it? PERF_EVENT_IOC_ENABLE and PERF_EVENT_IOC_DISABLE seem to apply to the entire set of processes that have inherited the counter. So if "enabled" and "disabled" are global states associated with the counter, rather than with individual processes, then it's silly to think of using enable_on_exec to limit by process. The fact that it seems to work in many cases, then, may be an accident. Or I could be talking complete nonsense here. Benjamin -- 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
