Messages in this thread | | | Subject | Re: [PATCH] io_uring: Add to traces the req pointer when available | From | Olivier Langlois <> | Date | Tue, 25 May 2021 17:26:47 -0400 |
| |
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...
| |