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@firstfloor.org/
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
From: Namhyung Kim <namhyung@kernel.org> Date: 2023-10-24 19:16:49
Hi Andi,
On Mon, Oct 23, 2023 at 2:58 PM Andi Kleen [off-list ref] wrote:
Namhyung Kim [off-list ref] writes:
quoted
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.
Oh, I wasn't aware of this series. I'll take a look.
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.
Right, I think dealing with regular samples would be more useful.
But Intel PT support looks interesting.
Perhaps it would be possible merge the useful parts of the two approaches?
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.
Right, I think dealing with regular samples would be more useful.
My code supported samples too, but only through perf script, not report.
See
https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/commit/?h=perf/var-resolve-7&id=4775664750a6296acb732b7adfa224c6a06a126f
for an example.
My take was that i wasn't sure that perf report is the right interface
to visualize the variables changing -- to be really usable you probably
need some plots and likely something like an UI.
For you I think you focus more on the types than the individual
variables? That's a slightly different approach.
But then my engine had a lot of limitations, i suppose redoing that on
top of yours would give better results.
-Andi
From: Namhyung Kim <namhyung@kernel.org> Date: 2023-10-25 05:52:07
On Tue, Oct 24, 2023 at 7:09 PM Andi Kleen [off-list ref] wrote:
quoted
quoted
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.
Right, I think dealing with regular samples would be more useful.
On Tue, Oct 24, 2023 at 10:51:41PM -0700, Namhyung Kim wrote:
On Tue, Oct 24, 2023 at 7:09 PM Andi Kleen [off-list ref] wrote:
quoted
quoted
quoted
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.
Right, I think dealing with regular samples would be more useful.
I see. Your concern is to see how variables are changing.
But it seems you only displayed constant values.
Yes the examples were not very good, but that was the intention.
Values can be much more powerful than only types!
For PT I also had special compiler patch that added suitable ptwrites
(see [1]) that allowed to track any variable.
-Andi
[1] https://github.com/andikleen/gcc-old-svn/tree/ptwrite-18