linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Milian Wolff <mail@milianw.de>
Cc: linux-perf-users <linux-perf-users@vger.kernel.org>
Subject: Re: Perf event for Wall-time based sampling?
Date: Thu, 18 Sep 2014 10:23:50 -0300	[thread overview]
Message-ID: <20140918132350.GE2770@kernel.org> (raw)
In-Reply-To: <2221771.b2oSN5LR6X@milian-kdab2>

Em Thu, Sep 18, 2014 at 02:32:10PM +0200, Milian Wolff escreveu:
> Hello,
> 
> is it somehow possible to use perf based on some kernel timer? I'd like to get 

Try with tracepoints or with probe points combined with callchains
instead of using a hardware counter.

- Arnaldo

> an overview of where a userspace application is spending time, both on-CPU as 
> well as waiting off-CPU. E.g. something similar to using GDB as a poor-mans 
> profiler and regularly interrupting the process and investigating the 
> callgraphs. This is quite efficient for a high-level overview when you want to 
> figure out where time is spent, unrelated to how it was actually spent (cpu, 
> thread locks, io wait, ...).
> 
> E.g. what event would I use for a simple application like this:
> 
> ~~~~~~~~~~~~~~
> #include <unistd.h>
> 
> int main()
> {
>   sleep(10);
>   return 0;
> }
> ~~~~~~~~~~~~~~
> 
> Which perf event would show me that most of the time is spent sleeping? I 
> tried something like this to no avail:
> 
> $ perf record --call-graph dwarf -e cpu-clock -F 100 ./a.out 
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.007 MB perf.data (~304 samples) ]
> perf report --stdio
> Error:
> The perf.data file has no samples!
> # To display the perf.data header info, please use --header/--header-only 
> options.
> 
> I read https://perf.wiki.kernel.org/index.php/Tutorial#Profiling_sleep_times
> and tried it out. The result is odd, as I get the "same" backtrace multiple 
> times, all with 100% cost:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>    100.00%     0.00%             0    a.out  libc-2.19.so       [.] 
> __GI___libc_nanosleep
>               |
>               --- __GI___libc_nanosleep
> 
>    100.00%     0.00%             0    a.out  [kernel.kallsyms]  [k] 
> system_call_fastpath 
>               |
>               --- system_call_fastpath
>                   __GI___libc_nanosleep
> 
>    100.00%     0.00%             0    a.out  [kernel.kallsyms]  [k] 
> sys_nanosleep        
>               |
>               --- sys_nanosleep
>                   system_call_fastpath
>                   __GI___libc_nanosleep
> 
>    100.00%     0.00%             0    a.out  [kernel.kallsyms]  [k] 
> hrtimer_nanosleep    
>               |
>               --- hrtimer_nanosleep
>                   sys_nanosleep
>                   system_call_fastpath
>                   __GI___libc_nanosleep
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> And generally, this would *only* profile sleep time and would ignore the on-
> CPU time (and maybe thread waits) and so forth.
> 
> Is there a technical reason on why it is not possible to use a plain timer as 
> a sampling event? If I'm not mistaken, then Intel VTune actually uses a 
> similar technique for its simple profiling modes which can already give 
> extremely useful data - both to find CPU hotspots as well as locks&waits.
> 
> Bye
> -- 
> Milian Wolff
> mail@milianw.de
> http://milianw.de
> --
> 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

  reply	other threads:[~2014-09-18 13:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 12:32 Perf event for Wall-time based sampling? Milian Wolff
2014-09-18 13:23 ` Arnaldo Carvalho de Melo [this message]
2014-09-18 13:41   ` Milian Wolff
2014-09-18 14:51     ` Arnaldo Carvalho de Melo
2014-09-18 15:26       ` Milian Wolff
2014-09-18 15:57         ` Arnaldo Carvalho de Melo
2014-09-18 16:37           ` Milian Wolff
2014-09-18 19:17             ` Arnaldo Carvalho de Melo
2014-09-18 19:31               ` Arnaldo Carvalho de Melo
2014-09-18 20:17               ` David Ahern
2014-09-18 20:36                 ` Arnaldo Carvalho de Melo
2014-09-18 20:39                   ` David Ahern
2014-09-19  8:11                   ` Milian Wolff
2014-09-19  9:08                     ` Milian Wolff
2014-09-19 14:47                     ` Arnaldo Carvalho de Melo
2014-09-19 15:04                       ` David Ahern
2014-09-19 15:05                       ` Milian Wolff
2014-09-19 14:17                   ` David Ahern
2014-09-19 14:39                     ` Milian Wolff
2014-09-19 14:55                       ` David Ahern
2014-09-19  5:59               ` Namhyung Kim
2014-09-19 14:33                 ` Arnaldo Carvalho de Melo
2014-09-19 14:53                   ` Milian Wolff
2014-09-19 15:50                     ` Namhyung Kim
2014-09-22  7:56                 ` Namhyung Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140918132350.GE2770@kernel.org \
    --to=acme@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mail@milianw.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).