On 10/25/24 00:25, Jens Axboe wrote:
On 10/24/24 12:10 PM, Pavel Begunkov wrote:
On 10/24/24 18:31, Jens Axboe wrote:
On Sat, Oct 12, 2024 at 3:30?AM Ruyi Zhang <ruyi.zhang@xxxxxxxxxxx> wrote:
...
I don't think there is any difference, it'd be a matter of
doubling the number of in flight timeouts to achieve same
timings. Tell me, do you really have a good case where you
need that (pretty verbose)? Why not drgn / bpftrace it out
of the kernel instead?
Of course, this information is available through existing tools.
But I think that most of the io_uring metadata has been exported
from the fdinfo file, and the purpose of adding the timeout
information is the same as before, easier to use. This way,
I don't have to write additional scripts to get all kinds of data.
And as far as I know, the io_uring_show_fdinfo function is
only called once when the user is viewing the
/proc/xxx/fdinfo/x file once. I don't think we normally need to
look at this file as often, and only look at it when the program
is abnormal, and the timeout_list is very long in the extreme case,
so I think the performance impact of adding this code is limited.
I do think it's useful, sometimes the only thing you have to poke at
after-the-fact is the fdinfo information. At the same time, would it be
If you have an fd to print fdinfo, you can just well run drgn
or any other debugging tool. We keep pushing more debugging code
that can be extracted with bpf and other tools, and not only
it bloats the code, but potentially cripples the entire kernel.
While that is certainly true, it's also a much harder barrier to entry.
If you're already setup with eg drgn, then yeah fdinfo is useless as you
can grab much more info out by just using drgn.
drgn is simple, not that harder than patching fdinfo, we can add
liburing/scripts, and push it there so that don't need rewriting
it each time.
I'm fine punting this to "needs more advanced debugging than fdinfo".
It's just important we get closure on these patches, so they don't
linger forever in no man's land.
The only option I see is to dump first ~5 and stop there, but
I still think the tooling option is better.
--
Pavel Begunkov
