perf annotate with sample counts

perf annotate with sample counts

[Paul Clarke]

Is there a way to get perf annotate to display sample counts instead of, 
or in addition to, percentages?

The percentages seem relative to the function, which isn't as helpful in 
a global context.

Regards,
PC

Re: perf annotate with sample counts

[Martin Liška]

On 07/16/2015 02:55 AM, Paul Clarke wrote:
> Is there a way to get perf annotate to display sample counts instead of, or in addition to, percentages?
> 
> The percentages seem relative to the function, which isn't as helpful in a global context.
> 
> Regards,
> PC

Hello Paul.

I think you are exactly looking for: https://lkml.org/lkml/2015/6/19/742, which
I implemented couple of weeks ago :)

Martin

> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: perf annotate with sample counts

[Paul Clarke]

On 07/16/2015 03:00 AM, Martin Liška wrote:
> On 07/16/2015 02:55 AM, Paul Clarke wrote:
>> Is there a way to get perf annotate to display sample counts instead of, or in addition to, percentages?
>>
>> The percentages seem relative to the function, which isn't as helpful in a global context.

> I think you are exactly looking for: https://lkml.org/lkml/2015/6/19/742, which
> I implemented couple of weeks ago :)

Near-perfect timing, I guess!  Thanks, Martin!

Do you have any sample output?  I don't see any in that thread.

Isn't this function analogous to perf report's "-n, --show-nr-samples" 
option?  For consistency and usability, would it not be better to use 
those options instead of "--show-total-period" ?

Thanks again!
PC

Re: perf annotate with sample counts

[Martin Liška]

On 07/16/2015 02:44 PM, Paul Clarke wrote:
> On 07/16/2015 03:00 AM, Martin Liška wrote:
>> On 07/16/2015 02:55 AM, Paul Clarke wrote:
>>> Is there a way to get perf annotate to display sample counts instead of, or in addition to, percentages?
>>>
>>> The percentages seem relative to the function, which isn't as helpful in a global context.
> 
>> I think you are exactly looking for: https://lkml.org/lkml/2015/6/19/742, which
>> I implemented couple of weeks ago :)
> 
> Near-perfect timing, I guess!  Thanks, Martin!
> 
> Do you have any sample output?  I don't see any in that thread.
> 
> Isn't this function analogous to perf report's "-n, --show-nr-samples" option?  For consistency and usability, would it not be better to use those options instead of "--show-total-period" ?
> 
> Thanks again!
> PC
> 

Hello.

Agree with you that it should be renamed to --show-nr-samples, I can come with a patch for that.

There's samples output:
 Percent |	Source code & Disassembly of cc1plus for cycles
---------------------------------------------------------------
         :
         :
         :
         :	Disassembly of section .text:
         :
         :	000000000059c480 <ggc_internal_alloc(unsigned long, void (*)(void*), unsigned long, unsigned long)>:
         :	_Z18ggc_internal_allocmPFvPvEmm():
         :	      new_entry = alloc_page (order);
         :
         :	      new_entry->index_by_depth = G.by_depth_in_use;
         :	      push_by_depth (new_entry, 0);
         :
         :	      /* We can skip context depths, if we do, make sure we go all the
      13 :	  59c480:       push   %r15
      40 :	  59c482:       push   %r14
       9 :	  59c484:       mov    %rdx,%r15
       1 :	  59c487:       push   %r13
       0 :	  59c489:       push   %r12
      13 :	  59c48b:       mov    %rsi,%r13
       4 :	  59c48e:       push   %rbp
       5 :	  59c48f:       push   %rbx
       6 :	  59c490:       mov    %rcx,%r14
         :	ggc_round_alloc_size_1():
         :	}
         :
         :	/* For a given size of memory requested for allocation, return the
         :	   actual size that is going to be allocated.  */
         :
         :	size_t
       5 :	  59c493:       mov    $0xa,%r12d
         :	_Z18ggc_internal_allocmPFvPvEmm():
         :	      new_entry = alloc_page (order);
         :
         :	      new_entry->index_by_depth = G.by_depth_in_use;
         :	      push_by_depth (new_entry, 0);
         :
         :	      /* We can skip context depths, if we do, make sure we go all the
       2 :	  59c499:       sub    $0x38,%rsp
         :	ggc_round_alloc_size_1():
         :	}
         :
         :	/* For a given size of memory requested for allocation, return the
         :	   actual size that is going to be allocated.  */
         :
         :	size_t
      10 :	  59c49d:       cmp    $0x1ff,%rdi
       0 :	  59c4a4:       ja     59ca52 <ggc_internal_alloc(unsigned long, void (*)(void*), unsigned long, unsigned long)+0x5d2>
         :	ggc_round_alloc_size (size_t requested_size)

w/o the option:

 Percent |	Source code & Disassembly of cc1plus for cycles
---------------------------------------------------------------
         :
         :
         :
         :	Disassembly of section .text:
         :
         :	000000000059c480 <ggc_internal_alloc(unsigned long, void (*)(void*), unsigned long, unsigned long)>:
         :	_Z18ggc_internal_allocmPFvPvEmm():
         :	      new_entry = alloc_page (order);
         :
         :	      new_entry->index_by_depth = G.by_depth_in_use;
         :	      push_by_depth (new_entry, 0);
         :
         :	      /* We can skip context depths, if we do, make sure we go all the
    0.92 :	  59c480:       push   %r15
    2.83 :	  59c482:       push   %r14
    0.64 :	  59c484:       mov    %rdx,%r15
    0.07 :	  59c487:       push   %r13
    0.00 :	  59c489:       push   %r12
    0.92 :	  59c48b:       mov    %rsi,%r13
    0.28 :	  59c48e:       push   %rbp
    0.35 :	  59c48f:       push   %rbx
    0.42 :	  59c490:       mov    %rcx,%r14
         :	ggc_round_alloc_size_1():
         :	}
         :
         :	/* For a given size of memory requested for allocation, return the
         :	   actual size that is going to be allocated.  */
         :
         :	size_t
    0.35 :	  59c493:       mov    $0xa,%r12d
         :	_Z18ggc_internal_allocmPFvPvEmm():
         :	      new_entry = alloc_page (order);
         :
         :	      new_entry->index_by_depth = G.by_depth_in_use;
         :	      push_by_depth (new_entry, 0);
         :
         :	      /* We can skip context depths, if we do, make sure we go all the
    0.14 :	  59c499:       sub    $0x38,%rsp
         :	ggc_round_alloc_size_1():
         :	}
         :
         :	/* For a given size of memory requested for allocation, return the
         :	   actual size that is going to be allocated.  */
         :
         :	size_t
    0.71 :	  59c49d:       cmp    $0x1ff,%rdi
    0.00 :	  59c4a4:       ja     59ca52 <ggc_internal_alloc(unsigned long, void (*)(void*), unsigned long, unsigned long)+0x5d2>
         :	ggc_round_alloc_size (size_t requested_size)

Martin

Re: perf annotate with sample counts

[Paul Clarke]

On 07/16/2015 07:52 AM, Martin Liška wrote:
> On 07/16/2015 02:44 PM, Paul Clarke wrote:
>> On 07/16/2015 03:00 AM, Martin Liška wrote:
>>> On 07/16/2015 02:55 AM, Paul Clarke wrote:
>>>> Is there a way to get perf annotate to display sample counts instead of, or in addition to, percentages?
>>>>
>>>> The percentages seem relative to the function, which isn't as helpful in a global context.
>>
>>> I think you are exactly looking for: https://lkml.org/lkml/2015/6/19/742, which
>>> I implemented couple of weeks ago :)
>>
>> Near-perfect timing, I guess!  Thanks, Martin!

>> Isn't this function analogous to perf report's "-n, --show-nr-samples" option?  For consistency and usability, would it not be better to use those options instead of "--show-total-period" ?

> Agree with you that it should be renamed to --show-nr-samples, I can come with a patch for that.

Could you include "-n" as a synonym, just like perf report?  That's 
exactly what I tried at first to see if it was supported with perf annotate.

Really appreciate it!

PC