On Fri, Sep 28, 2012 at 4:57 PM, Andi Kleen <a...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/