Re: perf trace report with time consumed

[Milian Wolff <milian.wolff@kdab.com>]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Dienstag, 5. April 2016 10:35:24 CEST Jiri Olsa wrote:
> On Mon, Apr 04, 2016 at 11:17:11PM +0200, Milian Wolff wrote:
> 
> SNIP
> 
> >             7f688a5ef0c4 usleep (/usr/lib/libc-2.23.so)
> >             5582244227cd main (/tmp/ex_sleep)
> >   
> >   1001.702 ( 0.059 ms): ex_sleep/4390 nanosleep(rqtp: 0x7ffe4d16eec0
> > 
> > ) = 0
> > 
> >                   20379e syscall_slow_exit_work ([kernel.kallsyms])
> >                   203bc4 syscall_return_slowpath ([kernel.kallsyms])
> >                   797248 int_ret_from_sys_call ([kernel.kallsyms])
> >             
> >             7f688a5c5600 __nanosleep (/usr/lib/libc-2.23.so)
> >             7f688a5ef0c4 usleep (/usr/lib/libc-2.23.so)
> >             5582244227d7 main (/tmp/ex_sleep)
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Is there a way to increase the event buffer or something like that to not
> > lose events when the costly dwarf unwinding happens for the first time?
> > Consecutive unwinding is cached by libunwind and much faster.
> 
> not sure about perf trace, but there's -m option available for perf record
> that allows you to increase the buffer size

<snip>

Yes, trace also knows the -m and even passing "-m 1M" already makes it the 
above use-case work. What is the default value? Could/Should it maybe be 
increased? 1M is not a lot of memory, sounds like a good trade-off to me?

Bye

-- 
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]