[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2frzr2cebxes2qoxofwqshfkb5k3d7jeq72srqnt4ywrlpkz5r@7pzb7cpbm4yw>
Date: Fri, 30 Jan 2026 09:44:47 +0100
From: Dmitry Dolgov <9erthalion6@...il.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: linux-perf-users@...r.kernel.org, Namhyung Kim <namhyung@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1] perf tests: Test annotate with data type
profiling and rust
> On Tue, Jan 27, 2026 at 02:00:07PM -0300, Arnaldo Carvalho de Melo wrote:
> I think this should be split into at least two patchs, one introducing
> the new workload and then the new perf test.
Makes sense, will do.
> Isn't that 'perf record' just using cycles? Wouldn't it be better to use
> 'perf mem record'?
'perf record' was an example I've picked up from LPC 2025 talk about
this, but I can switch it to 'perf mem record' as well.
> I don't have rust installed in this container, in this case we need some
> sort of capability query to tell the user that rust is needed for this
> feature to be present in perf.
Right, after some experimenting I think it would be a good idea to add a
new feature into tools/build/feature called "rust" and hide the workload
and the test behind it.
> I see, it doesn't work if I use 'make O=/some/directory/ -C tools/perf'
Ouch, I have to admit I haven't tested it that way, need to figure out
what's different in this case.
> acme@...ber:~/git/perf-tools-next$ sudo tools/perf/perf annotate -f --code-with-type
>
> Again, [Type] is there, but no types:
>
> Samples: 4K of event 'ibs_op/ldlat=0/', 4000 Hz, Event count (approx.): 5414001952
> test_rs /home/acme/git/perf-tools-next/tools/perf/perf [Percent: local period] [Type]
> 0.14 │ sub $0x98,%rsp
> │ mov %edi,0x2c(%rsp)
> │ mov %edi,0x84(%rsp)
> │ lea _IO_stdin_used+0x20,%rsi
> 0.07 │ lea 0x60(%rsp),%rdi
> 0.07 │ mov $0x4,%edx
> │ → call <alloc::string::String as core::convert::From<&str>>::f
>
> I'm not managing to reproduce your results, can you please elaborate
> some more?
That's most unexpected for me, the test output I see looks like this:
: 54 for _ in 1..count {
0.00 : 5423b8: mov %ecx,0x7c(%rsp)
0.00 : 5423bc: mov %eax,0x80(%rsp)
0.00 : 5423c3: lea 0x7c(%rsp),%rdi
12.28 : 5423c8: call 541f00 <core::iter::range::<impl core::iter::traits::iterator::Iterator for core::ops::range::Range<A>>::next>
0.00 : 5423cd: mov %eax,0x20(%rsp)
10.21 : 5423d1: jmp 5423d3 <test_rs+0xb3>
0.00 : 5423d3: mov 0x20(%rsp),%eax
0.00 : 5423d7: mov %eax,%eax
0.00 : 5423d9: test $0x1,%rax
0.29 : 5423df: je 5423f6 <test_rs+0xd6>
: 65 b.data1 += 1;
13.69 : 5423e1: mov 0x48(%rsp),%rax # data-type: struct Buf +0x18 (data1)
0.00 : 5423e6: add $0x1,%rax
0.00 : 5423ea: mov %rax,0x18(%rsp) # data-type: u64 +0
0.00 : 5423ef: setb %al
11.17 : 5423f2: jb 54243a <test_rs+0x11a>
0.00 : 5423f4: jmp 542426 <test_rs+0x106>
0.00 : 5423f6: lea 0x30(%rsp),%rdi
: 73 }
Where '# data-type: struct Buf' is as far as I understand a manifestation of
data type profiling succeeding. But my environment has slightly different
version of rust -- I need to figure out what's going on here, thanks.
Powered by blists - more mailing lists