Re: [RFC PATCH v1] perf tests: Test annotate with data type profiling and rust

[Dmitry Dolgov]

> 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@number:~/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.