On 10/15/19 11:02 AM, Dmitrii Dolgov 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. Looks good to me, I've applied it for some testing. Thanks! -- Jens Axboe
