Re: [RFC 00/48] perf tools: Introduce data type profiling (v1)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [RFC 00/48] perf tools: Introduce data type profiling (v1)
- From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
- Date: Mon, 23 Oct 2023 14:58:08 -0700
- Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>, Jiri Olsa <jolsa@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ian Rogers <irogers@xxxxxxxxxx>, Adrian Hunter <adrian.hunter@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, linux-perf-users@xxxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Stephane Eranian <eranian@xxxxxxxxxx>, Masami Hiramatsu <mhiramat@xxxxxxxxxx>, linux-toolchains@xxxxxxxxxxxxxxx, linux-trace-devel@xxxxxxxxxxxxxxx, Ben Woodard <woodard@xxxxxxxxxx>, Joe Mario <jmario@xxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, David Blaikie <blaikie@xxxxxxxxxx>, Xu Liu <xliuprof@xxxxxxxxxx>, Kan Liang <kan.liang@xxxxxxxxxxxxxxx>, Ravi Bangoria <ravi.bangoria@xxxxxxx>
- In-reply-to: <20231012035111.676789-1-namhyung@kernel.org> (Namhyung Kim's message of "Wed, 11 Oct 2023 20:50:23 -0700")
- References: <20231012035111.676789-1-namhyung@kernel.org>
- User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux)
Namhyung Kim <namhyung@xxxxxxxxxx> writes:
> Hello,
>
> I'm happy to share my work on data type profiling. This is to associate
> PMU samples to data types they refer using DWARF debug information. So
> basically it depends on quality of PMU events and compiler for producing
> DWARF info. But it doesn't require any changes in the target program.
>
> As it's an early stage, I've targeted the kernel on x86 to reduce the
> amount of work but IIUC there's no fundamental blocker to apply it to
> other architectures and applications.
FWIW i posted a similar patchkit a long time ago
https://lore.kernel.org/lkml/20171128002321.2878-13-andi@xxxxxxxxxxxxxx/
It was on my list to resurrect that, it's great that you are doing
something similar.
The latest iteration (not posted) was here:
https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/log/?h=perf/var-resolve-7
The main difference seems to be that mine was more for perf script
(e.g. i supported PT decoding), while you are more focused on sampling.
I relied on the kprobes/uprobes engine, which unfortunately was always
quite slow and had many limitations.
Perhaps it would be possible merge the useful parts of the two approaches?
-Andi
[Index of Archives]
[Linux USB Development]
[Linux USB Development]
[Linux Audio Users]
[Yosemite Hiking]
[Linux Kernel]
[Linux SCSI]