Messages in this thread | | | Date | Fri, 28 Sep 2012 19:09:31 +0200 | Subject | Re: [PATCH 18/31] perf, core: Add a concept of a weightened sample | From | Stephane Eranian <> |
| |
On Fri, Sep 28, 2012 at 4:57 PM, Andi Kleen <andi@firstfloor.org> wrote: >> I came to the conclusion that yes we need something like a weight or cost >> as a generic way of reporting that in some modes the period is not really >> the right measure to evaluate the "cost" of an event. > > I'm not fully sure if you're for or against it. I think > the patch is mostly orthogonal to what you're proposing > I am for it. It does not have to be specific to TSX or PEBS-LL. I have one form of it in my PEBS-LL patch. And yes, it appears as a sort key (for memory sampling mode only right now).
> My main target is the TSX abort cost, the memory latencies > I just added as a bonus. > >> >> I was testing my PEBS Load Latency patch this week, I came to that >> conclusion. The way perf report sorts samples based on aggregated >> periods per IP does not work for PEBS Load Latency (and possibly other >> modes). The sorting needs to be based on some cost that may be distinct >> from the period. By default, it would be the period, but for PEBS LL that >> would be the latency of the load at a specific IP. That would more reflect >> was is going on. > > > I originally folded the weight into nr_events, but in the end it turned > out it's fairly useful to expose both explicitely as sort keys. > > In some cases you want the average weight, in others the total weight > (SUM(weight) * nr_events). I haven't tried to mess with the period > so far. > > -Andi
| |