[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120928145703.GR16230@one.firstfloor.org>
Date: Fri, 28 Sep 2012 16:57:03 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Stephane Eranian <eranian@...gle.com>
Cc: Andi Kleen <andi@...stfloor.org>,
LKML <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 18/31] perf, core: Add a concept of a weightened sample
> 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
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists