Messages in this thread | | | Date | Tue, 13 Mar 2012 10:11:18 +0900 | From | Namhyung Kim <> | Subject | Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2) |
| |
2012-03-13 3:05 AM, Arun Sharma wrote: > On 3/12/12 12:15 AM, Namhyung Kim wrote: >> I think it's because of the shared hist_entry. If a callchain is a >> subset of another, it will be marked as inclusive so that it cannot be >> contributed to total period. Say, there're two chains - X (a -> b -> c) >> and Y (a -> b), once __hists__add_entry_inclusive() was called on X, we >> have: >> >> a -> b -> c >> a -> b (inclusive) >> a (inclusive) >> >> And then, calling the function on Y should make: >> >> a -> b >> a (inclusive) >> >> However, since both callchains are in tree already they'll be shared and >> marked *inclusive*. Thus the total period will not increased at all for >> Y. Also I guess the reverse case - add Y first, and then X - will have >> the same result. > > Thanks for figuring this out. Looks like using a single bit (he->inclusive) is > insufficient. How about: > > struct hist_entry { > u64 period; > u64 period_self; > .. > }; > > Normal mode: period_self == period. > Inclusive mode: period_self will be zero for inclusive hist_entries. > Shared entries: we sum up both period and period_self. > > We can then compute total_period by summing up period_self. >
Yeah, I agree that we need that kind of code to handle total_period properly. Looking forward to your v3 :).
Thanks, Namhyung
| |