[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151126095709.GA7723@gmail.com>
Date: Thu, 26 Nov 2015 10:57:09 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "Wangnan (F)" <wangnan0@...wei.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Yunlong Song <yunlong.song@...wei.com>, paulus@...ba.org,
mingo@...hat.com, acme@...nel.org, linux-kernel@...r.kernel.org,
namhyung@...nel.org, ast@...nel.org,
masami.hiramatsu.pt@...achi.com, kan.liang@...el.com,
adrian.hunter@...el.com, jolsa@...nel.org, dsahern@...il.com,
bp@...en8.de, jean.pihet@...aro.org, rric@...nel.org,
xiakaixu@...wei.com, hekuang@...wei.com
Subject: Re: [PATCH] perf record: Add snapshot mode support for perf's
regular events
* Ingo Molnar <mingo@...nel.org> wrote:
> So if an overwrite-mode background tracing session is running, you don't even have
> to signal it to capture the ring-buffer: just open the ring-buffer fd in procfs,
> under /proc/XYZ/perf/ring-buffers/5.trace or so, and dump its current contents,
> assuming the task doing that has sufficient permissions - i.e.
> ptrace_may_access().
>
> We could even pretty-print some very basic version of the records from the kernel,
> via /proc/XYZ/perf/ring-buffers/5.txt, to support a tooling-less tracing modes.
> This way perf based tracing could be supported even on systems that have no
> writable filesystems.
With this 'cat' could be used to look at the current trace:
cat /proc/XYZ/perf/ring-buffers/5.txt
would result in 'perf script' alike output generated by the kernel:
$ cat /proc/XYZ/perf/ring-buffers/5.txt
perf 24816 63796.780079: 1 cycles:pp: ffffffff810603f8 native_write_msr_safe
perf 24816 63796.780083: 1 cycles:pp: ffffffff810603f8 native_write_msr_safe
perf 24816 63796.780086: 8 cycles:pp: ffffffff810603f8 native_write_msr_safe
perf 24816 63796.780089: 97 cycles:pp: ffffffff810603f8 native_write_msr_safe
perf 24816 63796.780092: 1237 cycles:pp: ffffffff8103450c intel_pmu_handle_irq
perf 24816 63796.780094: 13879 cycles:pp: ffffffff81204f23 setup_new_exec
sh 24816 63796.780104: 170378 cycles:pp: ffffffff811bc437 change_protection_range
sh 24816 63796.780145: 698206 cycles:pp: ffffffff813d22d7 clear_page_c_e
sh 24816 63796.780304: 1145748 cycles:pp: 7f60aca20bdb _dl_addr
sh 24817 63796.780400: 1 cycles:pp: ffffffff810603f8 native_write_msr_safe
sh 24817 63796.780403: 1 cycles:pp: ffffffff810603f8 native_write_msr_safe
sh 24817 63796.780406: 10 cycles:pp: ffffffff810603f8 native_write_msr_safe
sh 24817 63796.780409: 118 cycles:pp: ffffffff810603f8 native_write_msr_safe
... and you could use shell scripting to analyze it - just like with ftrace.
of course this would be simplified output - and you could still access or copy the
raw trace data as well, and use all the rich tooling and visualization features of
full perf.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists