From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Milian Wolff <mail@milianw.de>
Cc: linux-perf-users <linux-perf-users@vger.kernel.org>,
Namhyung Kim <namhyung@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Joseph Schuchart <joseph.schuchart@tu-dresden.de>
Subject: Re: Perf event for Wall-time based sampling?
Date: Thu, 18 Sep 2014 16:31:52 -0300 [thread overview]
Message-ID: <20140918193152.GL2770@kernel.org> (raw)
In-Reply-To: <20140918191713.GK2770@kernel.org>
Em Thu, Sep 18, 2014 at 04:17:13PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Sep 18, 2014 at 06:37:47PM +0200, Milian Wolff escreveu:
> > This was also why I asked my initial question, which I want to repeat once
> > more: Is there a technical reason to not offer a "timer" software event to
> > perf? I'm a complete layman when it comes to Kernel internals, but from a user
> > point of view this would be awesome:
>
> > perf record --call-graph dwarf -e sw-timer -F 100 someapplication
>
> > This command would then create a timer in the kernel with a 100Hz frequency.
> > Whenever it fires, the callgraphs of all threads in $someapplication are
> > sampled and written to perf.data. Is this technically not feasible? Or is it
> > simply not implemented?
What you want is a sysrq-t that goes all the way to userspace, right?
Try:
echo t > /proc/sysrq
dmesg
i.e. probably you want that when a thread goes to sleep, we can take a
sample with callchains, no?
With a 'ping 127.0.0.1' running, I get this for its process:
[19255.244315] ping S ffff88043e213100 0 6754 6548 0x00000080
[19255.244316] ffff880231693a80 0000000000000082 ffff88040ffb1940 0000000000013100
[19255.244317] ffff880231693fd8 0000000000013100 ffff880423c88000 ffff88040ffb1940
[19255.244318] ffffffff81efb1c0 ffff880231693ab0 00000001012131d1 ffffffff81efb1c0
[19255.244319] Call Trace:
[19255.244321] [<ffffffff816b93a9>] schedule+0x29/0x70
[19255.244322] [<ffffffff816bbf91>] schedule_timeout+0x151/0x270
[19255.244325] [<ffffffff815ac606>] __skb_recv_datagram+0x426/0x4d0
[19255.244328] [<ffffffff815ac6e2>] skb_recv_datagram+0x32/0x40
[19255.244330] [<ffffffff8161a1ad>] raw_recvmsg+0x7d/0x1b0
[19255.244331] [<ffffffff8162961c>] inet_recvmsg+0x6c/0x80
[19255.244333] [<ffffffff8159d42a>] sock_recvmsg+0x9a/0xd0
[19255.244345] [<ffffffff8159e1a2>] __sys_recvmsg+0x42/0x80
[19255.244346] [<ffffffff8159e1f2>] SyS_recvmsg+0x12/0x20
[19255.244348] [<ffffffff816bd412>] system_call_fastpath+0x16/0x1b
No? Trying to collect dwarf callchains after installing iputils-debuginfo (where /bin/ping
symtab is)...
> > I'm experimenting with a libunwind based profiler, and with some ugly signal
> > hackery I can now grab backtraces by sending my application SIGUSR1. Based on
>
> Humm, can't you do the same thing with perf? I.e. you send SIGUSR1 to
> your app with the frequency you want, and then hook a 'perf probe' into
> your signal... /me tries some stuff, will get back with results...
>
> > that, I can probably create a profiling tool that fits my needs. I just wonder
> > why one cannot do the same with perf.
>
> - Arnaldo
next prev parent reply other threads:[~2014-09-18 19:31 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
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 [this message]
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=20140918193152.GL2770@kernel.org \
--to=acme@kernel.org \
--cc=joseph.schuchart@tu-dresden.de \
--cc=linux-perf-users@vger.kernel.org \
--cc=mail@milianw.de \
--cc=mingo@kernel.org \
--cc=namhyung@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.