Hi Pavel, On Tue, 2021-05-25 at 09:33 +0100, Pavel Begunkov wrote: > On 5/25/21 9:21 AM, Pavel Begunkov wrote: > > On 5/25/21 6:54 AM, Olivier Langlois wrote: > > > The req pointer uniquely identify a specific request. > > > Having it in traces can provide valuable insights that is not > > > possible > > > to have if the calling process is reusing the same user_data value. > > > > How about hashing kernel pointers per discussed? Even if it's better > > to have it done by tracing or something as you mentioned, there is no > > such a thing at the moment, so should be done by hand. > > Or do you mean that it's already the case? Can anyone > confirm if so? I did consider your option but then I did some research on the pointer hashing idea. It turns out to be already addressed by the trace subsystem. Here is what I have found: whippet2 /sys/kernel/tracing # cat trace_options print-parent nosym-offset nosym-addr noverbose noraw nohex nobin noblock trace_printk annotate nouserstacktrace nosym-userobj noprintk-msg-only context-info nolatency-format record-cmd norecord-tgid overwrite nodisable_on_free irq-info markers noevent-fork nopause-on-trace hash-ptr function-trace nofunction-fork nodisplay-graph nostacktrace notest_nop_accept notest_nop_refuse hash-ptr option is enabled by default. I am not 100% sure to understand why I am getting naked pointer values when I am getting the traces with 'sudo perf': 9287.369 test/625 io_uring:io_uring_task_run(ctx: 0xffff8fbf9a834800, opcode: 22, user_data: 216454257090494477, result: 195) 9287.386 test/625 io_uring:io_uring_task_run(ctx: 0xffff8fbf9a834800, opcode: 22, user_data: 216454257090494477, result: 195) but the pointers should be hashed by trace. That would be nice if someone more knowledgeable about the tracing system could jump in and comment about the hash-ptr option and tell when it is applied and when it is not...
