Messages in this thread | | | Date | Thu, 15 Mar 2012 10:41:11 -0700 | From | Arun Sharma <> | Subject | Re: [PATCH 0/2] perf: add sort by inclusive time functionality (v2) |
| |
On 3/15/12 7:50 AM, Frederic Weisbecker wrote:
>> AFAIK, "sort" here means how perf identifies a sample event from >> others: "comm" will collect samples have same pid/comm, then "dso" >> will group samples belong to same library, and "symbol" will group >> again samples have same symbol name. This is what default sort order >> (comm,dso,symbol) does. > > Right this is about how we group the events into histograms. > If you sort by dso, you'll have one histogram per dso and events > will be added to the histogram matching their dso. > > Multiple sorting does the same with an "AND" between sort entries. > If you sort by dso,pid, you'll have one histogram per possible couple > of (dso,pid). > > Say you have dso1, dso2 and pid1 and pid2, then you get 4 possible histograms: > (dso1,pid1), (dso1,pid2), (dso2,pid1), (dso2,pid2) > ...assuming that over your events you have all these combinations. > > So this is how we group samples into histograms.
Agreed. It's a different sort order, but not necessarily a different sort dimension. I'm thinking "group by" vs "order by" in SQL here.
Re: adding a new top level flag, struct option options[] in builtin-report.c looks busy (especially for short options. Eg: -i is already taken).
I can see parallels between this and sort__branch_mode. Stephane: what do you think about putting this in a different namespace?
--sort-mode branch (sort__branch_mode) --sort-mode inclusive (sort__inclusive_mode)
-Arun
| |