> On Sun, Oct 13, 2019 at 5:41 PM Dmitrii Dolgov <9erthalion6@xxxxxxxxx> wrote: > > To trace io_uring activity one can get an information from workqueue and > io trace events, but looks like some parts could be hard to identify via > this approach. Making what happens inside io_uring more transparent is > important to be able to reason about many aspects of it, hence introduce > the set of tracing events. > > All such events could be roughly divided into two categories: > > * those, that are helping to understand correctness (from both kernel > and an application point of view). E.g. a ring creation, file > registration, or waiting for available CQE. Proposed approach is to > get a pointer to an original structure of interest (ring context, or > request), and then find relevant events. io_uring_queue_async_work > also exposes a pointer to work_struct, to be able to track down > corresponding workqueue events. > > * those, that provide performance related information. Mostly it's about > events that change the flow of requests, e.g. whether an async work > was queued, or delayed due to some dependencies. Another important > case is how io_uring optimizations (e.g. registered files) are > utilized. > > Signed-off-by: Dmitrii Dolgov <9erthalion6@xxxxxxxxx> > --- > v1: add io_uring_link trace event > v2: Extend io_uring events, to include not only io_uring_link, but other > events to cover important parts of the functionality To clarify, I refer to this one [1] as v1. Would be glad to get any feedback. [1]: https://lore.kernel.org/linux-block/CA+q6zcWqWAWG7UqzOekEH71XGUb24WpmJqe9juK94C4wq=1xsw@xxxxxxxxxxxxxx/T/
