On 2/19/21 4:44 PM, Stefan Metzmacher wrote: > Hi Jens, > >> tldr - instead of using kthreads that assume the identity of the original >> tasks for work that needs offloading to a thread, setup these workers as >> threads of the original task. >> >> Here's a first cut of moving away from kthreads for io_uring. It passes >> the test suite and various other testing I've done with it. It also >> performs better, both for workloads actually using the async offload, but >> also in general as we slim down structures and kill code from the hot path. >> >> The series is roughly split into these parts: >> >> - Patches 1-6, io_uring/io-wq prep patches >> - Patches 7-8, Minor arch/kernel support >> - Patches 9-15, switch from kthread to thread, remove state only needed >> for kthreads >> - Patches 16-18, remove now dead/unneeded PF_IO_WORKER restrictions >> >> Comments/suggestions welcome. I'm pretty happy with the series at this >> point, and particularly with how we end up cutting a lot of code while >> also unifying how sync vs async is presented. > > Thanks a lot! I was thinking hard about how to make all this easier to > understand and perform better in order to have the whole context > available natively for sendmsg/recvmsg, but also for the upcoming > uring_cmd(). > > And now all that code magically disappeared completely, wonderful :-) Glad to hear you like the approach! Yes, this will help both readability, performance, and maintainability. Pretty much a win all around imho. -- Jens Axboe
