On 3/4/21 12:46 PM, Linus Torvalds wrote: > On Thu, Mar 4, 2021 at 11:19 AM Jens Axboe wrote: >> >> Took a quick look at this, and I agree that's _much_ better. In fact, it >> boils down to just calling copy_process() and then having the caller do >> wake_up_new_task(). So not sure if it's worth adding an >> create_io_thread() helper, or just make copy_process() available >> instead. This is ignoring the trace point for now... > > I really don't want to expose copy_process() outside of kernel/fork.c. > > The whole three-phase "copy - setup - activate" model is a really > really good thing, and it's how we've done things internally almost > forever, but I really don't want to expose those middle stages to any > outsiders. > > So I'd really prefer a simple new "create_io_worker()", even if it's > literally just some four-line function that does > > p = copy_process(..); > if (!IS_ERR(p)) { > block all signals in p > set PF_IO_WORKER flag > wake_up_new_task(p); > } > return p; > > I very much want that to be inside kernel/fork.c and have all these > rules about creating new threads localized there. I agree, here are the two current patches. Just need to add the signal blocking, which I'd love to do in create_io_thread(), but seems to require either an allocation or provide a helper to do it in the thread itself (with an on-stack mask). Removes code, even with comment added. fs/io-wq.c | 68 ++++++++++++++++--------------------------------------------- fs/io-wq.h | 2 -- fs/io_uring.c | 29 ++++++++++++++------------ include/linux/sched/task.h | 2 ++ kernel/fork.c | 24 ++++++++++++++++++++++ 5 files changed, 59 insertions(+), 66 deletions(-) -- Jens Axboe