On Fri, 2012-09-07 at 10:20 +0900, Namhyung Kim wrote: > (Adding peterz in case he has a time to answer) > > On Thu, 6 Sep 2012 11:19:21 -0400, Vince Weaver wrote: > > On Tue, 4 Sep 2012, Namhyung Kim wrote: > >> > >> AFAIK the "inherit" field determines whether the event is inherited to a > >> child process/thread. The "inherit_stat" is only meaningful when the > >> "inherit" field is also set and it'll preserve (saved) event counts > >> between context switch of the inherited processes/threads. > > > > Thank you for taking the time to answer! > > > > I'm still trying to construct a test case that shows the difference but > > I'm failing.
inherit && inherit_stat preserves the counts per-task and issues a PERF_RECORD_READ when a task dies. This allows a per-task stat on an inherited process hierarchy. > > Aren't the stats *always* saved on context switch? No, they're normally swizzled around, the only thing we care about is the total event count for the entire task-set, not the count of the individual tasks. > > Does this affect what happens when you read the perf_event fd in the > > inherited threads, or only from the master thread? read() on an inherited event gives the total count of the entire hierarchy. > > What is the expected behavior if you set inherit_thread but do not set > > inherit? > > You meant inherit_stat, right? If so, it looks it'd be a nop since > there's no inherited events. Maybe the perf tools can be changed to > warn about that. Right that would be a pointless configuration. -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
