lkml.org 
[lkml]   [2013]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 16/29] perf, tools: Add support for weight v7
From
On Wed, Jan 23, 2013 at 7:02 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> As for the hack, I did not put in in my hist__add_mem_entry() but
>> rather in the caller.
>> For PEBS-LL, the period is not important. I think it counts the number
>> of loads/stores
>> and not just the qualifying ones. For loads, that means it counts all
>> loads and not just
>> the ones above the threshold, but I may be wrong.
>
> Users should just specify the right keys, with a sensible default
> for the event.
>
But what I was saying is that even when you specify sensible
sort keys, there is ALWAYS an implicit key added first which
is the period. That is what that resort function does.

For PEBS-LL I do force the sort period to:
local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked

But that's not enough,

One solution could be to make period an explicit sort key. It
may then be dropped by some measurements, e.g., when weight is
is used.


>>
>> > I had a similar thing in a really old version of my patches,
>> > but I gave it up because it was too unintuitive.
>> >
>> Well, but then it does not present a sensible view of the samples when weight is
>> more important than period.
>
> Right now weight is not sorted. So you can see the information, but it's
> not really nice. Longer term should fix sort.c to actually sort properly,
> then it'll work ok and be intuitive.
>
> I don't think hacks like making weight look like period are the right
> way to do it. I had those originally, but discarded them.
>
> sort.c just needs to sort properly on all keys.
>
I agree.


\
 
 \ /
  Last update: 2013-01-23 20:01    [W:0.051 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site