* [RFC PATCH v2 1/4] tools/build: Add a feature test for rust compiler
2026-02-08 12:22 [RFC PATCH v2 0/4] Test annotate with data type profiling Dmitrii Dolgov
@ 2026-02-08 12:22 ` Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload Dmitrii Dolgov
` (3 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Dmitrii Dolgov @ 2026-02-08 12:22 UTC (permalink / raw)
To: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo,
Ian Rogers
Cc: Dmitrii Dolgov
Add a feature test to identify if the rust compiler is available, so
that perf could build rust based worloads based on that.
Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
tools/build/Makefile.feature | 6 ++++--
tools/build/feature/Makefile | 7 +++++++
tools/build/feature/test-rust.rs | 4 ++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/builtin-check.c | 1 +
5 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 tools/build/feature/test-rust.rs
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 7f119eafc7c..64d21152fc8 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -100,7 +100,8 @@ FEATURE_TESTS_BASIC := \
disassembler-four-args \
disassembler-init-styled \
file-handle \
- libopenssl
+ libopenssl \
+ rust
# FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
# of all feature tests
@@ -149,7 +150,8 @@ FEATURE_DISPLAY ?= \
bpf \
libaio \
libzstd \
- libopenssl
+ libopenssl \
+ rust
#
# Declare group members of a feature to display the logical OR of the detection
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 5c15572d505..9ae69d85716 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -112,6 +112,9 @@ __BUILD = $(CC) $(CFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.c,$(@F)) $(
__BUILDXX = $(CXX) $(CXXFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.cpp,$(@F)) $(LDFLAGS)
BUILDXX = $(__BUILDXX) > $(@:.bin=.make.output) 2>&1
+__BUILDRS = $(RUSTC) $(RUSTC_FLAGS) -o $@ $(patsubst %.bin,%.rs,$(@F))
+ BUILDRS = $(__BUILDRS) > $(@:.bin=.make.output) 2>&1
+
###############################
$(OUTPUT)test-all.bin:
@@ -388,6 +391,10 @@ $(OUTPUT)test-libopenssl.bin:
$(OUTPUT)test-bpftool-skeletons.bin:
$(SYSTEM_BPFTOOL) version | grep '^features:.*skeletons' \
> $(@:.bin=.make.output) 2>&1
+
+$(OUTPUT)test-rust.bin:
+ $(BUILDRS) > $(@:.bin=.make.output) 2>&1
+
###############################
clean:
diff --git a/tools/build/feature/test-rust.rs b/tools/build/feature/test-rust.rs
new file mode 100644
index 00000000000..f2fc91cc4f6
--- /dev/null
+++ b/tools/build/feature/test-rust.rs
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
+fn main() {
+ println!("hi")
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index b683aab3ab9..94aecfe38b9 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -1153,6 +1153,17 @@ ifneq ($(NO_LIBTRACEEVENT),1)
endif
endif
+ifndef NO_RUST
+ ifneq ($(feature-rust), 1)
+ $(warning Rust is not found. Test workloads with rust are disabled.)
+ NO_RUST := 1
+ else
+ NO_RUST := 0
+ CFLAGS += -DHAVE_RUST_SUPPORT
+ $(call detected,CONFIG_RUST_SUPPORT)
+ endif
+endif
+
# Among the variables below, these:
# perfexecdir
# libbpf_include_dir
diff --git a/tools/perf/builtin-check.c b/tools/perf/builtin-check.c
index d19769a8f68..27a41beeadd 100644
--- a/tools/perf/builtin-check.c
+++ b/tools/perf/builtin-check.c
@@ -60,6 +60,7 @@ struct feature_status supported_features[] = {
FEATURE_STATUS("numa_num_possible_cpus", HAVE_LIBNUMA_SUPPORT),
FEATURE_STATUS("zlib", HAVE_ZLIB_SUPPORT),
FEATURE_STATUS("zstd", HAVE_ZSTD_SUPPORT),
+ FEATURE_STATUS("rust", HAVE_RUST_SUPPORT),
/* this should remain at end, to know the array end */
FEATURE_STATUS(NULL, _)
--
2.52.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload
2026-02-08 12:22 [RFC PATCH v2 0/4] Test annotate with data type profiling Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 1/4] tools/build: Add a feature test for rust compiler Dmitrii Dolgov
@ 2026-02-08 12:22 ` Dmitrii Dolgov
2026-02-09 17:29 ` Ian Rogers
2026-02-09 17:33 ` Ian Rogers
2026-02-08 12:22 ` [RFC PATCH v2 3/4] perf tests: Test annotate with data type profiling and rust Dmitrii Dolgov
` (2 subsequent siblings)
4 siblings, 2 replies; 21+ messages in thread
From: Dmitrii Dolgov @ 2026-02-08 12:22 UTC (permalink / raw)
To: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo,
Ian Rogers
Cc: Dmitrii Dolgov
The purpose of the workload is to gather samples of rust runtime. To
achiever that it has a dummy rust library linked with it. Per
recommendations for such scenarios [1], the rust library is statically
linked.
An example:
$ perf record perf test -w code_with_type
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ]
$ perf report --stdio --dso perf -s srcfile,srcline
45.16% ub_checks.rs ub_checks.rs:72
6.72% code_with_type.rs code_with_type.rs:15
6.64% range.rs range.rs:767
4.26% code_with_type.rs code_with_type.rs:21
4.23% range.rs range.rs:0
3.99% code_with_type.rs code_with_type.rs:16
[...]
[1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases
Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
tools/build/Makefile.build | 14 ++++++
tools/perf/Makefile.perf | 2 +-
tools/perf/tests/builtin-test.c | 4 ++
tools/perf/tests/tests.h | 4 ++
tools/perf/tests/workloads/Build | 5 +++
tools/perf/tests/workloads/code_with_type.c | 46 ++++++++++++++++++++
tools/perf/tests/workloads/code_with_type.rs | 23 ++++++++++
tools/scripts/Makefile.include | 2 +
8 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/tests/workloads/code_with_type.c
create mode 100644 tools/perf/tests/workloads/code_with_type.rs
diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 3584ff30860..60e65870eae 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -76,6 +76,14 @@ quiet_cmd_host_ld_multi = HOSTLD $@
cmd_host_ld_multi = $(if $(strip $(obj-y)),\
$(HOSTLD) -r -o $@ $(filter $(obj-y),$^),rm -f $@; $(HOSTAR) rcs $@)
+rust_common_cmd = \
+ $(RUSTC) $(rust_flags) \
+ --crate-type staticlib -L $(objtree)/rust/ \
+ --emit=dep-info=$(depfile),link
+
+quiet_cmd_rustc_a_rs = $(RUSTC) $(quiet_modtag) $@
+ cmd_rustc_a_rs = $(rust_common_cmd) -o $@ -g $< $(cmd_objtool)
+
ifneq ($(filter $(obj),$(hostprogs)),)
host = host_
endif
@@ -105,6 +113,12 @@ $(OUTPUT)%.s: %.c FORCE
$(call rule_mkdir)
$(call if_changed_dep,cc_s_c)
+# it's recommended to build a static rust library, when a foreight (to rust)
+# linker is used.
+$(OUTPUT)%.a: %.rs FORCE
+ $(call rule_mkdir)
+ $(call if_changed_dep,rustc_a_rs)
+
# bison and flex files are generated in the OUTPUT directory
# so it needs a separate rule to depend on them properly
$(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2a7e5814b15..a6d8ca3e923 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -271,7 +271,7 @@ ifeq ($(PYLINT),1)
PYLINT := $(shell which pylint 2> /dev/null)
endif
-export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
+export srctree OUTPUT RM CC CXX RUSTC LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
export HOSTCC HOSTLD HOSTAR HOSTCFLAGS SHELLCHECK MYPY PYLINT
include $(srctree)/tools/build/Makefile.include
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index e2490652f03..06507066213 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -154,6 +154,10 @@ static struct test_workload *workloads[] = {
&workload__landlock,
&workload__traploop,
&workload__inlineloop,
+
+#ifdef HAVE_RUST_SUPPORT
+ &workload__code_with_type,
+#endif
};
#define workloads__for_each(workload) \
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 1f0f8b267fb..f5f1238d1f7 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -242,6 +242,10 @@ DECLARE_WORKLOAD(landlock);
DECLARE_WORKLOAD(traploop);
DECLARE_WORKLOAD(inlineloop);
+#ifdef HAVE_RUST_SUPPORT
+DECLARE_WORKLOAD(code_with_type);
+#endif
+
extern const char *dso_to_test;
extern const char *test_objdump_path;
diff --git a/tools/perf/tests/workloads/Build b/tools/perf/tests/workloads/Build
index 866a00bd14a..2ef97f7affc 100644
--- a/tools/perf/tests/workloads/Build
+++ b/tools/perf/tests/workloads/Build
@@ -10,6 +10,11 @@ perf-test-y += landlock.o
perf-test-y += traploop.o
perf-test-y += inlineloop.o
+ifeq ($(CONFIG_RUST_SUPPORT),y)
+ perf-test-y += code_with_type.o
+ perf-test-y += code_with_type.a
+endif
+
CFLAGS_sqrtloop.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
CFLAGS_leafloop.o = -g -O0 -fno-inline -fno-omit-frame-pointer -U_FORTIFY_SOURCE
CFLAGS_brstack.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
diff --git a/tools/perf/tests/workloads/code_with_type.c b/tools/perf/tests/workloads/code_with_type.c
new file mode 100644
index 00000000000..65d7be7dac2
--- /dev/null
+++ b/tools/perf/tests/workloads/code_with_type.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <pthread.h>
+#include <stdlib.h>
+#include <signal.h>
+#include <unistd.h>
+#include <linux/compiler.h>
+#include "../tests.h"
+
+extern void test_rs(uint count);
+
+static volatile sig_atomic_t done;
+
+static void sighandler(int sig __maybe_unused)
+{
+ done = 1;
+}
+
+static int code_with_type(int argc, const char **argv)
+{
+ int sec = 1, num_loops = 100;
+
+ pthread_setname_np(pthread_self(), "perf-code-with-type");
+ if (argc > 0)
+ sec = atoi(argv[0]);
+
+ if (argc > 1)
+ num_loops = atoi(argv[1]);
+
+ signal(SIGINT, sighandler);
+ signal(SIGALRM, sighandler);
+ alarm(sec);
+
+ /*
+ * Rust doesn't have signal management in the standard library. To
+ * not deal with any external crates, offload signal handling to the
+ * outside code.
+ */
+ while (!done) {
+ test_rs(num_loops);
+ continue;
+ }
+
+ return 0;
+}
+
+DEFINE_WORKLOAD(code_with_type);
diff --git a/tools/perf/tests/workloads/code_with_type.rs b/tools/perf/tests/workloads/code_with_type.rs
new file mode 100644
index 00000000000..3b91e51919d
--- /dev/null
+++ b/tools/perf/tests/workloads/code_with_type.rs
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0
+
+// We're going to look for this structure in the data type profiling report
+#[allow(dead_code)]
+struct Buf {
+ data1: u64,
+ data2: String,
+ data3: u64,
+}
+
+#[no_mangle]
+pub extern "C" fn test_rs(count: u32) {
+ let mut b = Buf { data1: 0, data2: String::from("data"), data3: 0};
+
+ for _ in 1..count {
+ b.data1 += 1;
+ if b.data1 == 123 {
+ b.data1 += 1;
+ }
+
+ b.data3 += b.data1;
+ }
+}
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index ded48263dd5..b5ecf137feb 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -94,6 +94,8 @@ LLVM_STRIP ?= llvm-strip
# Some tools require bpftool
SYSTEM_BPFTOOL ?= bpftool
+RUSTC ?= rustc
+
ifeq ($(CC_NO_CLANG), 1)
EXTRA_WARNINGS += -Wstrict-aliasing=3
--
2.52.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload
2026-02-08 12:22 ` [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload Dmitrii Dolgov
@ 2026-02-09 17:29 ` Ian Rogers
2026-02-11 10:57 ` Dmitry Dolgov
2026-02-09 17:33 ` Ian Rogers
1 sibling, 1 reply; 21+ messages in thread
From: Ian Rogers @ 2026-02-09 17:29 UTC (permalink / raw)
To: Dmitrii Dolgov; +Cc: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo
On Sun, Feb 8, 2026 at 4:22 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> The purpose of the workload is to gather samples of rust runtime. To
> achiever that it has a dummy rust library linked with it. Per
> recommendations for such scenarios [1], the rust library is statically
> linked.
>
> An example:
>
> $ perf record perf test -w code_with_type
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ]
>
> $ perf report --stdio --dso perf -s srcfile,srcline
> 45.16% ub_checks.rs ub_checks.rs:72
> 6.72% code_with_type.rs code_with_type.rs:15
> 6.64% range.rs range.rs:767
> 4.26% code_with_type.rs code_with_type.rs:21
> 4.23% range.rs range.rs:0
> 3.99% code_with_type.rs code_with_type.rs:16
> [...]
>
> [1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
> tools/build/Makefile.build | 14 ++++++
> tools/perf/Makefile.perf | 2 +-
> tools/perf/tests/builtin-test.c | 4 ++
> tools/perf/tests/tests.h | 4 ++
> tools/perf/tests/workloads/Build | 5 +++
> tools/perf/tests/workloads/code_with_type.c | 46 ++++++++++++++++++++
> tools/perf/tests/workloads/code_with_type.rs | 23 ++++++++++
> tools/scripts/Makefile.include | 2 +
> 8 files changed, 99 insertions(+), 1 deletion(-)
> create mode 100644 tools/perf/tests/workloads/code_with_type.c
> create mode 100644 tools/perf/tests/workloads/code_with_type.rs
>
> diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
> index 3584ff30860..60e65870eae 100644
> --- a/tools/build/Makefile.build
> +++ b/tools/build/Makefile.build
> @@ -76,6 +76,14 @@ quiet_cmd_host_ld_multi = HOSTLD $@
> cmd_host_ld_multi = $(if $(strip $(obj-y)),\
> $(HOSTLD) -r -o $@ $(filter $(obj-y),$^),rm -f $@; $(HOSTAR) rcs $@)
>
> +rust_common_cmd = \
> + $(RUSTC) $(rust_flags) \
> + --crate-type staticlib -L $(objtree)/rust/ \
> + --emit=dep-info=$(depfile),link
Does this need to be cross compilation aware? I worry that we can
detect local Rust support but not have cross compilation support and
then perf tool cross compilation builds are broken.
Thanks,
Ian
> +
> +quiet_cmd_rustc_a_rs = $(RUSTC) $(quiet_modtag) $@
> + cmd_rustc_a_rs = $(rust_common_cmd) -o $@ -g $< $(cmd_objtool)
> +
> ifneq ($(filter $(obj),$(hostprogs)),)
> host = host_
> endif
> @@ -105,6 +113,12 @@ $(OUTPUT)%.s: %.c FORCE
> $(call rule_mkdir)
> $(call if_changed_dep,cc_s_c)
>
> +# it's recommended to build a static rust library, when a foreight (to rust)
> +# linker is used.
> +$(OUTPUT)%.a: %.rs FORCE
> + $(call rule_mkdir)
> + $(call if_changed_dep,rustc_a_rs)
> +
> # bison and flex files are generated in the OUTPUT directory
> # so it needs a separate rule to depend on them properly
> $(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 2a7e5814b15..a6d8ca3e923 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -271,7 +271,7 @@ ifeq ($(PYLINT),1)
> PYLINT := $(shell which pylint 2> /dev/null)
> endif
>
> -export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
> +export srctree OUTPUT RM CC CXX RUSTC LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
> export HOSTCC HOSTLD HOSTAR HOSTCFLAGS SHELLCHECK MYPY PYLINT
>
> include $(srctree)/tools/build/Makefile.include
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index e2490652f03..06507066213 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -154,6 +154,10 @@ static struct test_workload *workloads[] = {
> &workload__landlock,
> &workload__traploop,
> &workload__inlineloop,
> +
> +#ifdef HAVE_RUST_SUPPORT
> + &workload__code_with_type,
> +#endif
> };
>
> #define workloads__for_each(workload) \
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index 1f0f8b267fb..f5f1238d1f7 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -242,6 +242,10 @@ DECLARE_WORKLOAD(landlock);
> DECLARE_WORKLOAD(traploop);
> DECLARE_WORKLOAD(inlineloop);
>
> +#ifdef HAVE_RUST_SUPPORT
> +DECLARE_WORKLOAD(code_with_type);
> +#endif
> +
> extern const char *dso_to_test;
> extern const char *test_objdump_path;
>
> diff --git a/tools/perf/tests/workloads/Build b/tools/perf/tests/workloads/Build
> index 866a00bd14a..2ef97f7affc 100644
> --- a/tools/perf/tests/workloads/Build
> +++ b/tools/perf/tests/workloads/Build
> @@ -10,6 +10,11 @@ perf-test-y += landlock.o
> perf-test-y += traploop.o
> perf-test-y += inlineloop.o
>
> +ifeq ($(CONFIG_RUST_SUPPORT),y)
> + perf-test-y += code_with_type.o
> + perf-test-y += code_with_type.a
> +endif
> +
> CFLAGS_sqrtloop.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> CFLAGS_leafloop.o = -g -O0 -fno-inline -fno-omit-frame-pointer -U_FORTIFY_SOURCE
> CFLAGS_brstack.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> diff --git a/tools/perf/tests/workloads/code_with_type.c b/tools/perf/tests/workloads/code_with_type.c
> new file mode 100644
> index 00000000000..65d7be7dac2
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <pthread.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <unistd.h>
> +#include <linux/compiler.h>
> +#include "../tests.h"
> +
> +extern void test_rs(uint count);
> +
> +static volatile sig_atomic_t done;
> +
> +static void sighandler(int sig __maybe_unused)
> +{
> + done = 1;
> +}
> +
> +static int code_with_type(int argc, const char **argv)
> +{
> + int sec = 1, num_loops = 100;
> +
> + pthread_setname_np(pthread_self(), "perf-code-with-type");
> + if (argc > 0)
> + sec = atoi(argv[0]);
> +
> + if (argc > 1)
> + num_loops = atoi(argv[1]);
> +
> + signal(SIGINT, sighandler);
> + signal(SIGALRM, sighandler);
> + alarm(sec);
> +
> + /*
> + * Rust doesn't have signal management in the standard library. To
> + * not deal with any external crates, offload signal handling to the
> + * outside code.
> + */
> + while (!done) {
> + test_rs(num_loops);
> + continue;
> + }
> +
> + return 0;
> +}
> +
> +DEFINE_WORKLOAD(code_with_type);
> diff --git a/tools/perf/tests/workloads/code_with_type.rs b/tools/perf/tests/workloads/code_with_type.rs
> new file mode 100644
> index 00000000000..3b91e51919d
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.rs
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// We're going to look for this structure in the data type profiling report
> +#[allow(dead_code)]
> +struct Buf {
> + data1: u64,
> + data2: String,
> + data3: u64,
> +}
> +
> +#[no_mangle]
> +pub extern "C" fn test_rs(count: u32) {
> + let mut b = Buf { data1: 0, data2: String::from("data"), data3: 0};
> +
> + for _ in 1..count {
> + b.data1 += 1;
> + if b.data1 == 123 {
> + b.data1 += 1;
> + }
> +
> + b.data3 += b.data1;
> + }
> +}
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index ded48263dd5..b5ecf137feb 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -94,6 +94,8 @@ LLVM_STRIP ?= llvm-strip
> # Some tools require bpftool
> SYSTEM_BPFTOOL ?= bpftool
>
> +RUSTC ?= rustc
> +
> ifeq ($(CC_NO_CLANG), 1)
> EXTRA_WARNINGS += -Wstrict-aliasing=3
>
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload
2026-02-09 17:29 ` Ian Rogers
@ 2026-02-11 10:57 ` Dmitry Dolgov
0 siblings, 0 replies; 21+ messages in thread
From: Dmitry Dolgov @ 2026-02-11 10:57 UTC (permalink / raw)
To: Ian Rogers; +Cc: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo
> On Mon, Feb 09, 2026 at 09:29:49AM -0800, Ian Rogers wrote:
>
> > +rust_common_cmd = \
> > + $(RUSTC) $(rust_flags) \
> > + --crate-type staticlib -L $(objtree)/rust/ \
> > + --emit=dep-info=$(depfile),link
>
> Does this need to be cross compilation aware? I worry that we can
> detect local Rust support but not have cross compilation support and
> then perf tool cross compilation builds are broken.
Good point. It's supposed to be cross compilation aware, because
rust_flags must contain the --target argument. But after checking it
out, looks like this variable is not passed from Makefile.perf . I'll
need to fix it, it should be handled similarly to CFLAGS/CXXFLAGS.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload
2026-02-08 12:22 ` [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload Dmitrii Dolgov
2026-02-09 17:29 ` Ian Rogers
@ 2026-02-09 17:33 ` Ian Rogers
2026-02-11 10:02 ` Dmitry Dolgov
1 sibling, 1 reply; 21+ messages in thread
From: Ian Rogers @ 2026-02-09 17:33 UTC (permalink / raw)
To: Dmitrii Dolgov; +Cc: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo
On Sun, Feb 8, 2026 at 4:22 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> The purpose of the workload is to gather samples of rust runtime. To
> achiever that it has a dummy rust library linked with it. Per
> recommendations for such scenarios [1], the rust library is statically
> linked.
>
> An example:
>
> $ perf record perf test -w code_with_type
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ]
>
> $ perf report --stdio --dso perf -s srcfile,srcline
> 45.16% ub_checks.rs ub_checks.rs:72
> 6.72% code_with_type.rs code_with_type.rs:15
> 6.64% range.rs range.rs:767
> 4.26% code_with_type.rs code_with_type.rs:21
> 4.23% range.rs range.rs:0
> 3.99% code_with_type.rs code_with_type.rs:16
> [...]
>
> [1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
> tools/build/Makefile.build | 14 ++++++
> tools/perf/Makefile.perf | 2 +-
> tools/perf/tests/builtin-test.c | 4 ++
> tools/perf/tests/tests.h | 4 ++
> tools/perf/tests/workloads/Build | 5 +++
> tools/perf/tests/workloads/code_with_type.c | 46 ++++++++++++++++++++
> tools/perf/tests/workloads/code_with_type.rs | 23 ++++++++++
> tools/scripts/Makefile.include | 2 +
> 8 files changed, 99 insertions(+), 1 deletion(-)
> create mode 100644 tools/perf/tests/workloads/code_with_type.c
> create mode 100644 tools/perf/tests/workloads/code_with_type.rs
>
> diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
> index 3584ff30860..60e65870eae 100644
> --- a/tools/build/Makefile.build
> +++ b/tools/build/Makefile.build
> @@ -76,6 +76,14 @@ quiet_cmd_host_ld_multi = HOSTLD $@
> cmd_host_ld_multi = $(if $(strip $(obj-y)),\
> $(HOSTLD) -r -o $@ $(filter $(obj-y),$^),rm -f $@; $(HOSTAR) rcs $@)
>
> +rust_common_cmd = \
> + $(RUSTC) $(rust_flags) \
> + --crate-type staticlib -L $(objtree)/rust/ \
> + --emit=dep-info=$(depfile),link
> +
> +quiet_cmd_rustc_a_rs = $(RUSTC) $(quiet_modtag) $@
> + cmd_rustc_a_rs = $(rust_common_cmd) -o $@ -g $< $(cmd_objtool)
> +
> ifneq ($(filter $(obj),$(hostprogs)),)
> host = host_
> endif
> @@ -105,6 +113,12 @@ $(OUTPUT)%.s: %.c FORCE
> $(call rule_mkdir)
> $(call if_changed_dep,cc_s_c)
>
> +# it's recommended to build a static rust library, when a foreight (to rust)
> +# linker is used.
> +$(OUTPUT)%.a: %.rs FORCE
> + $(call rule_mkdir)
> + $(call if_changed_dep,rustc_a_rs)
> +
> # bison and flex files are generated in the OUTPUT directory
> # so it needs a separate rule to depend on them properly
> $(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 2a7e5814b15..a6d8ca3e923 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -271,7 +271,7 @@ ifeq ($(PYLINT),1)
> PYLINT := $(shell which pylint 2> /dev/null)
> endif
>
> -export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
> +export srctree OUTPUT RM CC CXX RUSTC LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
> export HOSTCC HOSTLD HOSTAR HOSTCFLAGS SHELLCHECK MYPY PYLINT
>
> include $(srctree)/tools/build/Makefile.include
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index e2490652f03..06507066213 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -154,6 +154,10 @@ static struct test_workload *workloads[] = {
> &workload__landlock,
> &workload__traploop,
> &workload__inlineloop,
> +
> +#ifdef HAVE_RUST_SUPPORT
> + &workload__code_with_type,
> +#endif
> };
>
> #define workloads__for_each(workload) \
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index 1f0f8b267fb..f5f1238d1f7 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -242,6 +242,10 @@ DECLARE_WORKLOAD(landlock);
> DECLARE_WORKLOAD(traploop);
> DECLARE_WORKLOAD(inlineloop);
>
> +#ifdef HAVE_RUST_SUPPORT
> +DECLARE_WORKLOAD(code_with_type);
> +#endif
> +
> extern const char *dso_to_test;
> extern const char *test_objdump_path;
>
> diff --git a/tools/perf/tests/workloads/Build b/tools/perf/tests/workloads/Build
> index 866a00bd14a..2ef97f7affc 100644
> --- a/tools/perf/tests/workloads/Build
> +++ b/tools/perf/tests/workloads/Build
> @@ -10,6 +10,11 @@ perf-test-y += landlock.o
> perf-test-y += traploop.o
> perf-test-y += inlineloop.o
>
> +ifeq ($(CONFIG_RUST_SUPPORT),y)
> + perf-test-y += code_with_type.o
> + perf-test-y += code_with_type.a
nit: It'd be more normal to write this as:
perf-test-$(CONFIG_RUST_SUPPORT) += code_with_type.o
perf-test-$(CONFIG_RUST_SUPPORT) += code_with_type.a
I did an update this morning but found I needed to install rustc to
get the build working. I'm not sure things work without rustc
installed as advertised.
Thanks,
Ian
> +endif
> +
> CFLAGS_sqrtloop.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> CFLAGS_leafloop.o = -g -O0 -fno-inline -fno-omit-frame-pointer -U_FORTIFY_SOURCE
> CFLAGS_brstack.o = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> diff --git a/tools/perf/tests/workloads/code_with_type.c b/tools/perf/tests/workloads/code_with_type.c
> new file mode 100644
> index 00000000000..65d7be7dac2
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <pthread.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <unistd.h>
> +#include <linux/compiler.h>
> +#include "../tests.h"
> +
> +extern void test_rs(uint count);
> +
> +static volatile sig_atomic_t done;
> +
> +static void sighandler(int sig __maybe_unused)
> +{
> + done = 1;
> +}
> +
> +static int code_with_type(int argc, const char **argv)
> +{
> + int sec = 1, num_loops = 100;
> +
> + pthread_setname_np(pthread_self(), "perf-code-with-type");
> + if (argc > 0)
> + sec = atoi(argv[0]);
> +
> + if (argc > 1)
> + num_loops = atoi(argv[1]);
> +
> + signal(SIGINT, sighandler);
> + signal(SIGALRM, sighandler);
> + alarm(sec);
> +
> + /*
> + * Rust doesn't have signal management in the standard library. To
> + * not deal with any external crates, offload signal handling to the
> + * outside code.
> + */
> + while (!done) {
> + test_rs(num_loops);
> + continue;
> + }
> +
> + return 0;
> +}
> +
> +DEFINE_WORKLOAD(code_with_type);
> diff --git a/tools/perf/tests/workloads/code_with_type.rs b/tools/perf/tests/workloads/code_with_type.rs
> new file mode 100644
> index 00000000000..3b91e51919d
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.rs
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// We're going to look for this structure in the data type profiling report
> +#[allow(dead_code)]
> +struct Buf {
> + data1: u64,
> + data2: String,
> + data3: u64,
> +}
> +
> +#[no_mangle]
> +pub extern "C" fn test_rs(count: u32) {
> + let mut b = Buf { data1: 0, data2: String::from("data"), data3: 0};
> +
> + for _ in 1..count {
> + b.data1 += 1;
> + if b.data1 == 123 {
> + b.data1 += 1;
> + }
> +
> + b.data3 += b.data1;
> + }
> +}
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index ded48263dd5..b5ecf137feb 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -94,6 +94,8 @@ LLVM_STRIP ?= llvm-strip
> # Some tools require bpftool
> SYSTEM_BPFTOOL ?= bpftool
>
> +RUSTC ?= rustc
> +
> ifeq ($(CC_NO_CLANG), 1)
> EXTRA_WARNINGS += -Wstrict-aliasing=3
>
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload
2026-02-09 17:33 ` Ian Rogers
@ 2026-02-11 10:02 ` Dmitry Dolgov
0 siblings, 0 replies; 21+ messages in thread
From: Dmitry Dolgov @ 2026-02-11 10:02 UTC (permalink / raw)
To: Ian Rogers; +Cc: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo
> On Mon, Feb 09, 2026 at 09:33:41AM -0800, Ian Rogers wrote:
>
> I did an update this morning but found I needed to install rustc to
> get the build working. I'm not sure things work without rustc
> installed as advertised.
Yeah, sorry for that. There are few fixes starting from 3f5dfa472ea
(tools build: Fix rust feature detection), which should address this.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [RFC PATCH v2 3/4] perf tests: Test annotate with data type profiling and rust
2026-02-08 12:22 [RFC PATCH v2 0/4] Test annotate with data type profiling Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 1/4] tools/build: Add a feature test for rust compiler Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload Dmitrii Dolgov
@ 2026-02-08 12:22 ` Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C Dmitrii Dolgov
2026-02-08 14:39 ` [RFC PATCH v2 0/4] Test annotate with data type profiling Arnaldo Carvalho de Melo
4 siblings, 0 replies; 21+ messages in thread
From: Dmitrii Dolgov @ 2026-02-08 12:22 UTC (permalink / raw)
To: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo,
Ian Rogers
Cc: Dmitrii Dolgov
Exercise the annotate command with data type profiling feature on the
rust runtime. For that add a new shell test, which will profile the
code_with_type workload, then annotate the result expecting to see some
data structures from the rust code.
Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
tools/perf/tests/shell/data_type_profiling.sh | 69 +++++++++++++++++++
1 file changed, 69 insertions(+)
create mode 100755 tools/perf/tests/shell/data_type_profiling.sh
diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
new file mode 100755
index 00000000000..cdc9adb7d70
--- /dev/null
+++ b/tools/perf/tests/shell/data_type_profiling.sh
@@ -0,0 +1,69 @@
+#!/bin/bash
+# perf data type profiling tests
+# SPDX-License-Identifier: GPL-2.0
+
+set -e
+
+# The logic below follows the same line as the annotate test, but looks for a
+# data type profiling manifestation
+testtype="# data-type: struct Buf"
+
+err=0
+perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
+perfout=$(mktemp /tmp/__perf_test.perf.out.XXXXX)
+testprog="perf test -w code_with_type"
+
+cleanup() {
+ rm -rf "${perfdata}" "${perfout}"
+ rm -rf "${perfdata}".old
+
+ trap - EXIT TERM INT
+}
+
+trap_cleanup() {
+ echo "Unexpected signal in ${FUNCNAME[1]}"
+ cleanup
+ exit 1
+}
+trap trap_cleanup EXIT TERM INT
+
+test_basic_annotate() {
+ mode=$1
+ echo "${mode} perf annotate test"
+ if [ "x${mode}" == "xBasic" ]
+ then
+ perf mem record -o "${perfdata}" ${testprog} 2> /dev/null
+ else
+ perf mem record -o - ${testprog} 2> /dev/null > "${perfdata}"
+ fi
+ if [ "x$?" != "x0" ]
+ then
+ echo "${mode} annotate [Failed: perf record]"
+ err=1
+ return
+ fi
+
+ # Generate the annotated output file
+ if [ "x${mode}" == "xBasic" ]
+ then
+ perf annotate --code-with-type -i "${perfdata}" --stdio --percent-limit 1 2> /dev/null > "${perfout}"
+ else
+ perf annotate --code-with-type -i - --stdio 2> /dev/null --percent-limit 1 < "${perfdata}" > "${perfout}"
+ fi
+
+ # check if it has the target data type
+ if ! grep -q "${testtype}" "${perfout}"
+ then
+ echo "${mode} annotate [Failed: missing target data type]"
+ cat "${perfout}"
+ err=1
+ return
+ fi
+ echo "${mode} annotate test [Success]"
+}
+
+test_basic_annotate Basic
+test_basic_annotate Pipe
+
+cleanup
+exit $err
--
2.52.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C
2026-02-08 12:22 [RFC PATCH v2 0/4] Test annotate with data type profiling Dmitrii Dolgov
` (2 preceding siblings ...)
2026-02-08 12:22 ` [RFC PATCH v2 3/4] perf tests: Test annotate with data type profiling and rust Dmitrii Dolgov
@ 2026-02-08 12:22 ` Dmitrii Dolgov
2026-02-10 5:39 ` Ian Rogers
2026-02-08 14:39 ` [RFC PATCH v2 0/4] Test annotate with data type profiling Arnaldo Carvalho de Melo
4 siblings, 1 reply; 21+ messages in thread
From: Dmitrii Dolgov @ 2026-02-08 12:22 UTC (permalink / raw)
To: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo,
Ian Rogers
Cc: Dmitrii Dolgov
Exercise the annotate command with data type profiling feature with C. For that
extend the existing data type profiling shell test to profile the datasym
workload, then annotate the result expecting to see some data structures from
the C code.
Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
tools/perf/tests/shell/data_type_profiling.sh | 31 ++++++++++++++-----
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
index cdc9adb7d70..a230f5d4c42 100755
--- a/tools/perf/tests/shell/data_type_profiling.sh
+++ b/tools/perf/tests/shell/data_type_profiling.sh
@@ -6,12 +6,14 @@ set -e
# The logic below follows the same line as the annotate test, but looks for a
# data type profiling manifestation
-testtype="# data-type: struct Buf"
+
+# Values in testtypes and testprogs should match
+testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
+testprogs=("perf test -w code_with_type" "perf test -w datasym")
err=0
perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
perfout=$(mktemp /tmp/__perf_test.perf.out.XXXXX)
-testprog="perf test -w code_with_type"
cleanup() {
rm -rf "${perfdata}" "${perfout}"
@@ -29,12 +31,23 @@ trap trap_cleanup EXIT TERM INT
test_basic_annotate() {
mode=$1
- echo "${mode} perf annotate test"
+ runtime=$2
+
+ echo "${mode} ${runtime} perf annotate test"
+
+ case "x${runtime}" in
+ "xRust")
+ index=0 ;;
+
+ "xC")
+ index=1 ;;
+ esac
+
if [ "x${mode}" == "xBasic" ]
then
- perf mem record -o "${perfdata}" ${testprog} 2> /dev/null
+ perf mem record -o "${perfdata}" ${testprogs[$index]} 2> /dev/null
else
- perf mem record -o - ${testprog} 2> /dev/null > "${perfdata}"
+ perf mem record -o - ${testprogs[$index]} 2> /dev/null > "${perfdata}"
fi
if [ "x$?" != "x0" ]
then
@@ -52,7 +65,7 @@ test_basic_annotate() {
fi
# check if it has the target data type
- if ! grep -q "${testtype}" "${perfout}"
+ if ! grep -q "${testtypes[$index]}" "${perfout}"
then
echo "${mode} annotate [Failed: missing target data type]"
cat "${perfout}"
@@ -62,8 +75,10 @@ test_basic_annotate() {
echo "${mode} annotate test [Success]"
}
-test_basic_annotate Basic
-test_basic_annotate Pipe
+test_basic_annotate Basic Rust
+test_basic_annotate Pipe Rust
+test_basic_annotate Basic C
+test_basic_annotate Pipe C
cleanup
exit $err
--
2.52.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C
2026-02-08 12:22 ` [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C Dmitrii Dolgov
@ 2026-02-10 5:39 ` Ian Rogers
2026-02-10 11:57 ` Dmitry Dolgov
0 siblings, 1 reply; 21+ messages in thread
From: Ian Rogers @ 2026-02-10 5:39 UTC (permalink / raw)
To: Dmitrii Dolgov; +Cc: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo
On Sun, Feb 8, 2026 at 4:23 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> Exercise the annotate command with data type profiling feature with C. For that
> extend the existing data type profiling shell test to profile the datasym
> workload, then annotate the result expecting to see some data structures from
> the C code.
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
> tools/perf/tests/shell/data_type_profiling.sh | 31 ++++++++++++++-----
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
> index cdc9adb7d70..a230f5d4c42 100755
> --- a/tools/perf/tests/shell/data_type_profiling.sh
> +++ b/tools/perf/tests/shell/data_type_profiling.sh
> @@ -6,12 +6,14 @@ set -e
>
> # The logic below follows the same line as the annotate test, but looks for a
> # data type profiling manifestation
> -testtype="# data-type: struct Buf"
> +
> +# Values in testtypes and testprogs should match
> +testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
So in the datasym workload the struct _buf is a typedef and the value
declared to be of the type of the typedef:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/workloads/datasym.c?h=perf-tools-next#n14
```
typedef struct _buf {
char data1;
char reserved[55];
char data2;
} buf __attribute__((aligned(64)));
/* volatile to try to avoid the compiler seeing reserved as unused. */
static volatile buf workload_datasym_buf1 = {
/* to have this in the data section */
.reserved[0] = 1,
};
```
This test is failing for me as I see "data-type: buf" rather than
"data-type: struct _buf" (ie the typedef rather than the struct):
```
0.00 : 201290: movzbl 0xbb5869(%rip), %eax # 0xdb6b00
<workload_datasym_buf1> # data-type: buf +0 (data1)
0.00 : 201297: addl $0x1, %eax
47.66 : 20129a: movb %al, 0xbb5860(%rip) # 0xdb6b00
<workload_datasym_buf1> # data-type: buf +0 (data1)
0.00 : 2012a0: movzbl 0xbb5859(%rip), %eax # 0xdb6b00
<workload_datasym_buf1> # data-type: buf +0 (data1)
0.00 : 2012a7: cmpb $0x7b, %al
0.00 : 2012a9: jne 0x2012bb <datasym+0x9c>
0.00 : 2012ab: movzbl 0xbb584e(%rip), %eax # 0xdb6b00
<workload_datasym_buf1> # data-type: buf +0 (data1)
0.00 : 2012b2: addl $0x1, %eax
0.25 : 2012b5: movb %al, 0xbb5845(%rip) # 0xdb6b00
<workload_datasym_buf1> # data-type: buf +0 (data1)
0.00 : 2012bb: movzbl 0xbb583e(%rip), %eax # 0xdb6b00
<workload_datasym_buf1> # data-type: buf +0 (data1)
0.00 : 2012c2: movzbl 0xbb586f(%rip), %edx # 0xdb6b38
<workload_datasym_buf1+0x38> # data-type: buf +0x38
(data2)
0.00 : 2012c9: addl %edx, %eax
52.10 : 2012cb: movb %al, 0xbb5867(%rip) # 0xdb6b38
<workload_datasym_buf1+0x38> # data-type: buf +0x38
(data2)
0.00 : 2012d1: movl 0xbc7861(%rip), %eax # 0xdc8b38
<done> # data-type: sig_atomic_t +0
```
It seems the typedef is a more accurate type name, so I think the test
is wrong here.
Thanks,
Ian
> +testprogs=("perf test -w code_with_type" "perf test -w datasym")
>
> err=0
> perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
> perfout=$(mktemp /tmp/__perf_test.perf.out.XXXXX)
> -testprog="perf test -w code_with_type"
>
> cleanup() {
> rm -rf "${perfdata}" "${perfout}"
> @@ -29,12 +31,23 @@ trap trap_cleanup EXIT TERM INT
>
> test_basic_annotate() {
> mode=$1
> - echo "${mode} perf annotate test"
> + runtime=$2
> +
> + echo "${mode} ${runtime} perf annotate test"
> +
> + case "x${runtime}" in
> + "xRust")
> + index=0 ;;
> +
> + "xC")
> + index=1 ;;
> + esac
> +
> if [ "x${mode}" == "xBasic" ]
> then
> - perf mem record -o "${perfdata}" ${testprog} 2> /dev/null
> + perf mem record -o "${perfdata}" ${testprogs[$index]} 2> /dev/null
> else
> - perf mem record -o - ${testprog} 2> /dev/null > "${perfdata}"
> + perf mem record -o - ${testprogs[$index]} 2> /dev/null > "${perfdata}"
> fi
> if [ "x$?" != "x0" ]
> then
> @@ -52,7 +65,7 @@ test_basic_annotate() {
> fi
>
> # check if it has the target data type
> - if ! grep -q "${testtype}" "${perfout}"
> + if ! grep -q "${testtypes[$index]}" "${perfout}"
> then
> echo "${mode} annotate [Failed: missing target data type]"
> cat "${perfout}"
> @@ -62,8 +75,10 @@ test_basic_annotate() {
> echo "${mode} annotate test [Success]"
> }
>
> -test_basic_annotate Basic
> -test_basic_annotate Pipe
> +test_basic_annotate Basic Rust
> +test_basic_annotate Pipe Rust
> +test_basic_annotate Basic C
> +test_basic_annotate Pipe C
>
> cleanup
> exit $err
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C
2026-02-10 5:39 ` Ian Rogers
@ 2026-02-10 11:57 ` Dmitry Dolgov
2026-03-02 23:58 ` [PATCH v1] perf test type profiling: Remote typedef on struct Ian Rogers
0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Dolgov @ 2026-02-10 11:57 UTC (permalink / raw)
To: Ian Rogers; +Cc: linux-perf-users, Namhyung Kim, Arnaldo Carvalho de Melo
> On Mon, Feb 09, 2026 at 09:39:09PM -0800, Ian Rogers wrote:
> > # The logic below follows the same line as the annotate test, but looks for a
> > # data type profiling manifestation
> > -testtype="# data-type: struct Buf"
> > +
> > +# Values in testtypes and testprogs should match
> > +testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
>
> So in the datasym workload the struct _buf is a typedef and the value
> declared to be of the type of the typedef:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/workloads/datasym.c?h=perf-tools-next#n14
> ```
> typedef struct _buf {
> char data1;
> char reserved[55];
> char data2;
> } buf __attribute__((aligned(64)));
>
> /* volatile to try to avoid the compiler seeing reserved as unused. */
> static volatile buf workload_datasym_buf1 = {
> /* to have this in the data section */
> .reserved[0] = 1,
> };
> ```
> This test is failing for me as I see "data-type: buf" rather than
> "data-type: struct _buf" (ie the typedef rather than the struct):
> ```
> 0.00 : 201290: movzbl 0xbb5869(%rip), %eax # 0xdb6b00
> <workload_datasym_buf1> # data-type: buf +0 (data1)
> 0.00 : 201297: addl $0x1, %eax
> 47.66 : 20129a: movb %al, 0xbb5860(%rip) # 0xdb6b00
> <workload_datasym_buf1> # data-type: buf +0 (data1)
> 0.00 : 2012a0: movzbl 0xbb5859(%rip), %eax # 0xdb6b00
> <workload_datasym_buf1> # data-type: buf +0 (data1)
> 0.00 : 2012a7: cmpb $0x7b, %al
> 0.00 : 2012a9: jne 0x2012bb <datasym+0x9c>
> 0.00 : 2012ab: movzbl 0xbb584e(%rip), %eax # 0xdb6b00
> <workload_datasym_buf1> # data-type: buf +0 (data1)
> 0.00 : 2012b2: addl $0x1, %eax
> 0.25 : 2012b5: movb %al, 0xbb5845(%rip) # 0xdb6b00
> <workload_datasym_buf1> # data-type: buf +0 (data1)
> 0.00 : 2012bb: movzbl 0xbb583e(%rip), %eax # 0xdb6b00
> <workload_datasym_buf1> # data-type: buf +0 (data1)
> 0.00 : 2012c2: movzbl 0xbb586f(%rip), %edx # 0xdb6b38
> <workload_datasym_buf1+0x38> # data-type: buf +0x38
> (data2)
> 0.00 : 2012c9: addl %edx, %eax
> 52.10 : 2012cb: movb %al, 0xbb5867(%rip) # 0xdb6b38
> <workload_datasym_buf1+0x38> # data-type: buf +0x38
> (data2)
> 0.00 : 2012d1: movl 0xbc7861(%rip), %eax # 0xdc8b38
> <done> # data-type: sig_atomic_t +0
> ```
> It seems the typedef is a more accurate type name, so I think the test
> is wrong here.
That's interesting, I don't see "data-type: buf" for this particular test, but
I've noticed that "perf annotate" reports different data types (buf vs _buf) in
certain cases. E.g. if as in the test, the data is collected via
perf mem record
then I get "data-type: struct _buf". But if we do
perf record
then I get "data-type: buf". Interestingly enough, all the addresses looks the
same, except the final type_die in the end:
# perf record
find data type for 0xa00e69(PC) at datasym+0x71
CU for tests/workloads/datasym.c (die:0x1ddfcf)
found by addr=0xf7e000 type_offset=0
type='buf' size=0x39 (die:0x1de132)
final result: type='buf' size=0x39 (die:0x1de132)
# perf mem record
find data type for 0xa00e69(PC) at datasym+0x71
CU for tests/workloads/datasym.c (die:0x1ddfcf)
found by addr=0xf7e000 type_offset=0
type='struct _buf' size=0x39 (die:0x1de0ed)
final result: type='struct _buf' size=0x39 (die:0x1de0ed)
Not sure what to make of it, still trying to figure out where it's coming from.
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v1] perf test type profiling: Remote typedef on struct
2026-02-10 11:57 ` Dmitry Dolgov
@ 2026-03-02 23:58 ` Ian Rogers
2026-03-04 10:44 ` Dmitry Dolgov
2026-03-04 21:48 ` Namhyung Kim
0 siblings, 2 replies; 21+ messages in thread
From: Ian Rogers @ 2026-03-02 23:58 UTC (permalink / raw)
To: 9erthalion6
Cc: miguel.ojeda.sandonis, a.hindborg, acme, aliceryhl, bjorn3_gh,
boqun, dakr, gary, irogers, linux-kernel, linux-perf-users,
lossin, namhyung, ojeda, rust-for-linux, tmgross
The typedef creates an issue where the struct or the typedef may
appear in the output and cause the "perf data type profiling tests" to
fail. Let's remove the typedef to keep the test passing.
Fixes: 335047109d7d ("perf tests: Test annotate with data type profiling and C")
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/perf/tests/shell/data_type_profiling.sh | 2 +-
tools/perf/tests/workloads/datasym.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
index 2a7f8f7c42d0..fb47b7213b33 100755
--- a/tools/perf/tests/shell/data_type_profiling.sh
+++ b/tools/perf/tests/shell/data_type_profiling.sh
@@ -8,7 +8,7 @@ set -e
# data type profiling manifestation
# Values in testtypes and testprogs should match
-testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
+testtypes=("# data-type: struct Buf" "# data-type: struct buf")
testprogs=("perf test -w code_with_type" "perf test -w datasym")
err=0
diff --git a/tools/perf/tests/workloads/datasym.c b/tools/perf/tests/workloads/datasym.c
index 1d0b7d64e1ba..19242c7255c0 100644
--- a/tools/perf/tests/workloads/datasym.c
+++ b/tools/perf/tests/workloads/datasym.c
@@ -4,14 +4,14 @@
#include <linux/compiler.h>
#include "../tests.h"
-typedef struct _buf {
+struct buf {
char data1;
char reserved[55];
char data2;
-} buf __attribute__((aligned(64)));
+} __attribute__((aligned(64)));
/* volatile to try to avoid the compiler seeing reserved as unused. */
-static volatile buf workload_datasym_buf1 = {
+static volatile struct buf workload_datasym_buf1 = {
/* to have this in the data section */
.reserved[0] = 1,
};
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH v1] perf test type profiling: Remote typedef on struct
2026-03-02 23:58 ` [PATCH v1] perf test type profiling: Remote typedef on struct Ian Rogers
@ 2026-03-04 10:44 ` Dmitry Dolgov
2026-03-04 20:34 ` Arnaldo Carvalho de Melo
2026-03-04 21:48 ` Namhyung Kim
1 sibling, 1 reply; 21+ messages in thread
From: Dmitry Dolgov @ 2026-03-04 10:44 UTC (permalink / raw)
To: Ian Rogers
Cc: miguel.ojeda.sandonis, a.hindborg, acme, aliceryhl, bjorn3_gh,
boqun, dakr, gary, linux-kernel, linux-perf-users, lossin,
namhyung, ojeda, rust-for-linux, tmgross
> On Mon, Mar 02, 2026 at 03:58:21PM -0800, Ian Rogers wrote:
> The typedef creates an issue where the struct or the typedef may
> appear in the output and cause the "perf data type profiling tests" to
> fail. Let's remove the typedef to keep the test passing.
Yes, makes sense to me, thanks. As mentioned in the previous message, it
sounds fishy to me that perf record and perf mem record capture
different data type -- I'll try to get to the bottom of it (I was sort
of hoping to finish the cross compilation topic first, but since it's
not moving that fast, why not do some debugging here).
Reviewed-by: Dmitrii Dolgov <9erthalion6@gmail.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1] perf test type profiling: Remote typedef on struct
2026-03-04 10:44 ` Dmitry Dolgov
@ 2026-03-04 20:34 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 21+ messages in thread
From: Arnaldo Carvalho de Melo @ 2026-03-04 20:34 UTC (permalink / raw)
To: Dmitry Dolgov
Cc: Ian Rogers, miguel.ojeda.sandonis, a.hindborg, aliceryhl,
bjorn3_gh, boqun, dakr, gary, linux-kernel, linux-perf-users,
lossin, namhyung, ojeda, rust-for-linux, tmgross
On Wed, Mar 04, 2026 at 11:44:16AM +0100, Dmitry Dolgov wrote:
> > On Mon, Mar 02, 2026 at 03:58:21PM -0800, Ian Rogers wrote:
> > The typedef creates an issue where the struct or the typedef may
> > appear in the output and cause the "perf data type profiling tests" to
> > fail. Let's remove the typedef to keep the test passing.
>
> Yes, makes sense to me, thanks. As mentioned in the previous message, it
> sounds fishy to me that perf record and perf mem record capture
> different data type -- I'll try to get to the bottom of it (I was sort
> of hoping to finish the cross compilation topic first, but since it's
> not moving that fast, why not do some debugging here).
>
> Reviewed-by: Dmitrii Dolgov <9erthalion6@gmail.com>
Thanks, applied to perf-tools, for v7.0.
- Arnaldo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1] perf test type profiling: Remote typedef on struct
2026-03-02 23:58 ` [PATCH v1] perf test type profiling: Remote typedef on struct Ian Rogers
2026-03-04 10:44 ` Dmitry Dolgov
@ 2026-03-04 21:48 ` Namhyung Kim
2026-03-04 22:04 ` Arnaldo Carvalho de Melo
1 sibling, 1 reply; 21+ messages in thread
From: Namhyung Kim @ 2026-03-04 21:48 UTC (permalink / raw)
To: 9erthalion6, Ian Rogers
Cc: a.hindborg, acme, aliceryhl, bjorn3_gh, boqun, dakr, gary,
linux-kernel, linux-perf-users, lossin, ojeda, rust-for-linux,
tmgross, Miguel Ojeda
On Mon, 02 Mar 2026 15:58:21 -0800, Ian Rogers wrote:
> The typedef creates an issue where the struct or the typedef may
> appear in the output and cause the "perf data type profiling tests" to
> fail. Let's remove the typedef to keep the test passing.
>
>
Applied to perf-tools-next, thanks!
Best regards,
Namhyung
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1] perf test type profiling: Remote typedef on struct
2026-03-04 21:48 ` Namhyung Kim
@ 2026-03-04 22:04 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 21+ messages in thread
From: Arnaldo Carvalho de Melo @ 2026-03-04 22:04 UTC (permalink / raw)
To: Namhyung Kim
Cc: 9erthalion6, Ian Rogers, a.hindborg, aliceryhl, bjorn3_gh, boqun,
dakr, gary, linux-kernel, linux-perf-users, lossin, ojeda,
rust-for-linux, tmgross
On Wed, Mar 04, 2026 at 01:48:53PM -0800, Namhyung Kim wrote:
> On Mon, 02 Mar 2026 15:58:21 -0800, Ian Rogers wrote:
> > The typedef creates an issue where the struct or the typedef may
> > appear in the output and cause the "perf data type profiling tests" to
> > fail. Let's remove the typedef to keep the test passing.
> >
> >
> Applied to perf-tools-next, thanks!
I applied this to perf-tools as well, for now just at tmp.perf-tools
tho.
- Arnaldo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH v2 0/4] Test annotate with data type profiling
2026-02-08 12:22 [RFC PATCH v2 0/4] Test annotate with data type profiling Dmitrii Dolgov
` (3 preceding siblings ...)
2026-02-08 12:22 ` [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C Dmitrii Dolgov
@ 2026-02-08 14:39 ` Arnaldo Carvalho de Melo
2026-02-08 14:42 ` Rust data-type profiling working in perf was: " Arnaldo Carvalho de Melo
4 siblings, 1 reply; 21+ messages in thread
From: Arnaldo Carvalho de Melo @ 2026-02-08 14:39 UTC (permalink / raw)
To: Dmitrii Dolgov; +Cc: linux-perf-users, Namhyung Kim, Ian Rogers
On Sun, Feb 08, 2026 at 01:22:22PM +0100, Dmitrii Dolgov wrote:
> Add shell tests for data type profiling, including C and rust.
>
> To support the rust test, a new workload with rust code was introduced.
> To build it only when rust is actually available, also add a feature
> test for rust compiler and guard everything behind it.
>
> Changes in v2:
> - Switched to use mem record.
> - Fixed the build issue with a custom output.
> - Separated patches for the workload and tests.
> - Added new test for C code.
> - Added a feature test for rust compiler.
Thanks, tested it, everything working as advertised:
⬢ [acme@toolbx perf-tools-next]$ m
make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD: Doing 'make -j32' parallel build
Warning: Kernel ABI header differences:
diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
diff -u tools/perf/arch/s390/entry/syscalls/syscall.tbl arch/s390/kernel/syscalls/syscall.tbl
Auto-detecting system features:
... libdw: [ on ]
... glibc: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libpython: [ on ]
... libcapstone: [ on ]
... llvm-perf: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... libzstd: [ on ]
... libopenssl: [ on ]
... rust: [ on ] <-------------------------
INSTALL libsubcmd_headers
<SNIP>
⬢ [acme@toolbx perf-tools-next]$ perf record perf test -w code_with_type
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.162 MB perf.data (4036 samples) ]
⬢ [acme@toolbx perf-tools-next]$ perf report --stdio --dso perf -s srcfile,srcline | head -20
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 4K of event 'cpu/cycles/Pu'
# Event count (approx.): 5337677712
#
# Overhead Source File Source:Line
# ........ ................. ..............................................................
#
25.53% cmp.rs cmp.rs:1903
16.66% code_with_type.rs code_with_type.rs:15
14.48% ub_checks.rs ub_checks.rs:68
11.16% range.rs range.rs:204
6.39% range.rs range.rs:0
4.61% range.rs range.rs:849
3.78% code_with_type.rs code_with_type.rs:13
3.51% code_with_type.rs code_with_type.rs:21
2.89% range.rs range.rs:764
⬢ [acme@toolbx perf-tools-next]$ grep -m1 'model name' /proc/cpuinfo
model name : AMD Ryzen 9 9950X3D 16-Core Processor
⬢ [acme@toolbx perf-tools-next]$ uname -a
Linux toolbx 6.18.8-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 30 20:23:28 UTC 2026 x86_64 GNU/Linux
⬢ [acme@toolbx perf-tools-next]$
root@number:~# perf test 'perf data type profiling tests'
83: perf data type profiling tests : Ok
root@number:~# perf test -vv 'perf data type profiling tests'
83: perf data type profiling tests:
--- start ---
test child forked, pid 125028
Basic Rust perf annotate test
Basic annotate test [Success]
Pipe Rust perf annotate test
Pipe annotate test [Success]
Basic C perf annotate test
Basic annotate test [Success]
Pipe C perf annotate test
Pipe annotate test [Success]
---- end(0) ----
83: perf data type profiling tests : Ok
root@number:~#
Thanks, applied to perf-tools-next,
- Arnaldo
- Arnaldo
> Dmitrii Dolgov (4):
> tools/build: Add a feature test for rust compiler
> perf test workload: Add code_with_type test workload
> perf tests: Test annotate with data type profiling and rust
> perf tests: Test annotate with data type profiling and C
>
> tools/build/Makefile.build | 14 ++++
> tools/build/Makefile.feature | 6 +-
> tools/build/feature/Makefile | 7 ++
> tools/build/feature/test-rust.rs | 4 +
> tools/perf/Makefile.config | 11 +++
> tools/perf/Makefile.perf | 2 +-
> tools/perf/builtin-check.c | 1 +
> tools/perf/tests/builtin-test.c | 4 +
> tools/perf/tests/shell/data_type_profiling.sh | 84 +++++++++++++++++++
> tools/perf/tests/tests.h | 4 +
> tools/perf/tests/workloads/Build | 5 ++
> tools/perf/tests/workloads/code_with_type.c | 46 ++++++++++
> tools/perf/tests/workloads/code_with_type.rs | 23 +++++
> tools/scripts/Makefile.include | 2 +
> 14 files changed, 210 insertions(+), 3 deletions(-)
> create mode 100644 tools/build/feature/test-rust.rs
> create mode 100755 tools/perf/tests/shell/data_type_profiling.sh
> create mode 100644 tools/perf/tests/workloads/code_with_type.c
> create mode 100644 tools/perf/tests/workloads/code_with_type.rs
>
>
> base-commit: 36a1b0061a584430277861fe5d8bd107aef26137
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling
2026-02-08 14:39 ` [RFC PATCH v2 0/4] Test annotate with data type profiling Arnaldo Carvalho de Melo
@ 2026-02-08 14:42 ` Arnaldo Carvalho de Melo
2026-02-08 15:16 ` Miguel Ojeda
2026-02-09 8:45 ` Dmitry Dolgov
0 siblings, 2 replies; 21+ messages in thread
From: Arnaldo Carvalho de Melo @ 2026-02-08 14:42 UTC (permalink / raw)
To: Dmitrii Dolgov
Cc: Miguel Ojeda, linux-perf-users, Namhyung Kim, Ian Rogers,
Linux Kernel Mailing List
On Sun, Feb 08, 2026 at 11:39:28AM -0300, Arnaldo Carvalho de Melo wrote:
> On Sun, Feb 08, 2026 at 01:22:22PM +0100, Dmitrii Dolgov wrote:
> > Add shell tests for data type profiling, including C and rust.
> > To support the rust test, a new workload with rust code was introduced.
> > To build it only when rust is actually available, also add a feature
> > test for rust compiler and guard everything behind it.
> > Changes in v2:
> > - Switched to use mem record.
> > - Fixed the build issue with a custom output.
> > - Separated patches for the workload and tests.
> > - Added new test for C code.
> > - Added a feature test for rust compiler.
> Thanks, tested it, everything working as advertised:
This is an interesting piece of news, so CCing to lkml and Miguel as
well, please CC that list in the future.
Also please consider adding examples of output of such new features, so
that people can quickly see it in action, data-type profiling for Rust
seems interesting, right? :-)
- Arnaldo
> ⬢ [acme@toolbx perf-tools-next]$ m
> make: Entering directory '/home/acme/git/linux/tools/perf'
> BUILD: Doing 'make -j32' parallel build
> Warning: Kernel ABI header differences:
> diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
> diff -u tools/perf/arch/s390/entry/syscalls/syscall.tbl arch/s390/kernel/syscalls/syscall.tbl
>
> Auto-detecting system features:
> ... libdw: [ on ]
> ... glibc: [ on ]
> ... libelf: [ on ]
> ... libnuma: [ on ]
> ... numa_num_possible_cpus: [ on ]
> ... libpython: [ on ]
> ... libcapstone: [ on ]
> ... llvm-perf: [ on ]
> ... zlib: [ on ]
> ... lzma: [ on ]
> ... bpf: [ on ]
> ... libaio: [ on ]
> ... libzstd: [ on ]
> ... libopenssl: [ on ]
> ... rust: [ on ] <-------------------------
>
> INSTALL libsubcmd_headers
> <SNIP>
>
> ⬢ [acme@toolbx perf-tools-next]$ perf record perf test -w code_with_type
> [ perf record: Woken up 2 times to write data ]
> [ perf record: Captured and wrote 0.162 MB perf.data (4036 samples) ]
> ⬢ [acme@toolbx perf-tools-next]$ perf report --stdio --dso perf -s srcfile,srcline | head -20
> # To display the perf.data header info, please use --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 4K of event 'cpu/cycles/Pu'
> # Event count (approx.): 5337677712
> #
> # Overhead Source File Source:Line
> # ........ ................. ..............................................................
> #
> 25.53% cmp.rs cmp.rs:1903
> 16.66% code_with_type.rs code_with_type.rs:15
> 14.48% ub_checks.rs ub_checks.rs:68
> 11.16% range.rs range.rs:204
> 6.39% range.rs range.rs:0
> 4.61% range.rs range.rs:849
> 3.78% code_with_type.rs code_with_type.rs:13
> 3.51% code_with_type.rs code_with_type.rs:21
> 2.89% range.rs range.rs:764
> ⬢ [acme@toolbx perf-tools-next]$ grep -m1 'model name' /proc/cpuinfo
> model name : AMD Ryzen 9 9950X3D 16-Core Processor
> ⬢ [acme@toolbx perf-tools-next]$ uname -a
> Linux toolbx 6.18.8-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 30 20:23:28 UTC 2026 x86_64 GNU/Linux
> ⬢ [acme@toolbx perf-tools-next]$
>
> root@number:~# perf test 'perf data type profiling tests'
> 83: perf data type profiling tests : Ok
> root@number:~# perf test -vv 'perf data type profiling tests'
> 83: perf data type profiling tests:
> --- start ---
> test child forked, pid 125028
> Basic Rust perf annotate test
> Basic annotate test [Success]
> Pipe Rust perf annotate test
> Pipe annotate test [Success]
> Basic C perf annotate test
> Basic annotate test [Success]
> Pipe C perf annotate test
> Pipe annotate test [Success]
> ---- end(0) ----
> 83: perf data type profiling tests : Ok
> root@number:~#
>
> Thanks, applied to perf-tools-next,
>
> - Arnaldo
> > Dmitrii Dolgov (4):
> > tools/build: Add a feature test for rust compiler
> > perf test workload: Add code_with_type test workload
> > perf tests: Test annotate with data type profiling and rust
> > perf tests: Test annotate with data type profiling and C
> >
> > tools/build/Makefile.build | 14 ++++
> > tools/build/Makefile.feature | 6 +-
> > tools/build/feature/Makefile | 7 ++
> > tools/build/feature/test-rust.rs | 4 +
> > tools/perf/Makefile.config | 11 +++
> > tools/perf/Makefile.perf | 2 +-
> > tools/perf/builtin-check.c | 1 +
> > tools/perf/tests/builtin-test.c | 4 +
> > tools/perf/tests/shell/data_type_profiling.sh | 84 +++++++++++++++++++
> > tools/perf/tests/tests.h | 4 +
> > tools/perf/tests/workloads/Build | 5 ++
> > tools/perf/tests/workloads/code_with_type.c | 46 ++++++++++
> > tools/perf/tests/workloads/code_with_type.rs | 23 +++++
> > tools/scripts/Makefile.include | 2 +
> > 14 files changed, 210 insertions(+), 3 deletions(-)
> > create mode 100644 tools/build/feature/test-rust.rs
> > create mode 100755 tools/perf/tests/shell/data_type_profiling.sh
> > create mode 100644 tools/perf/tests/workloads/code_with_type.c
> > create mode 100644 tools/perf/tests/workloads/code_with_type.rs
> >
> > base-commit: 36a1b0061a584430277861fe5d8bd107aef26137
> > --
> > 2.52.0
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling
2026-02-08 14:42 ` Rust data-type profiling working in perf was: " Arnaldo Carvalho de Melo
@ 2026-02-08 15:16 ` Miguel Ojeda
2026-02-09 8:45 ` Dmitry Dolgov
1 sibling, 0 replies; 21+ messages in thread
From: Miguel Ojeda @ 2026-02-08 15:16 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Dmitrii Dolgov, Miguel Ojeda, linux-perf-users, Namhyung Kim,
Ian Rogers, Linux Kernel Mailing List, rust-for-linux, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich
On Sun, Feb 8, 2026 at 3:42 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> This is an interesting piece of news, so CCing to lkml and Miguel as
> well, please CC that list in the future.
>
> Also please consider adding examples of output of such new features, so
> that people can quickly see it in action, data-type profiling for Rust
> seems interesting, right? :-)
Thanks Arnaldo for the ping!
Cc'ing rust-for-linux as well.
Thread at https://lore.kernel.org/all/20260208122227.3524-1-9erthalion6@gmail.com/
Cheers,
Miguel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling
2026-02-08 14:42 ` Rust data-type profiling working in perf was: " Arnaldo Carvalho de Melo
2026-02-08 15:16 ` Miguel Ojeda
@ 2026-02-09 8:45 ` Dmitry Dolgov
2026-02-10 1:26 ` Namhyung Kim
1 sibling, 1 reply; 21+ messages in thread
From: Dmitry Dolgov @ 2026-02-09 8:45 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Miguel Ojeda, linux-perf-users, Namhyung Kim, Ian Rogers,
Linux Kernel Mailing List
> On Sun, Feb 08, 2026 at 11:42:28AM -0300, Arnaldo Carvalho de Melo wrote:
>
> Also please consider adding examples of output of such new features, so
> that people can quickly see it in action, data-type profiling for Rust
> seems interesting, right? :-)
Agree :) What would be the right place to put such examples, somewhere
in the documentation?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling
2026-02-09 8:45 ` Dmitry Dolgov
@ 2026-02-10 1:26 ` Namhyung Kim
0 siblings, 0 replies; 21+ messages in thread
From: Namhyung Kim @ 2026-02-10 1:26 UTC (permalink / raw)
To: Dmitry Dolgov
Cc: Arnaldo Carvalho de Melo, Miguel Ojeda, linux-perf-users,
Ian Rogers, Linux Kernel Mailing List
On Mon, Feb 09, 2026 at 09:45:32AM +0100, Dmitry Dolgov wrote:
> > On Sun, Feb 08, 2026 at 11:42:28AM -0300, Arnaldo Carvalho de Melo wrote:
> >
> > Also please consider adding examples of output of such new features, so
> > that people can quickly see it in action, data-type profiling for Rust
> > seems interesting, right? :-)
>
> Agree :) What would be the right place to put such examples, somewhere
> in the documentation?
Yep, please add it to the documentation.
Thanks,
Namhyung
^ permalink raw reply [flat|nested] 21+ messages in thread