> >>> > >>> I wonder what is the case for io_uring, since read is now async, will > >>> kthread have the user thread's PKUR ? > >> > >> There is no kthread. What can happen is that some operation may be > >> punted to the io-wq workers, but these act exactly like a thread created > >> by the original task. IOW, if normal threads retain the protection key, > >> so will any io-wq io_uring thread. If they don't, they do not. > >> > > Does this also apply to when the IORING_SETUP_SQPOLL [1] flag is used > > ? it mentions a kernel thread is created to perform submission queue > > polling. > > It doesn't matter if it's SQPOLL or one of the io-wq workers, they are > created in the same way. For all intents and purposes, they are > userspace threads, identical to one you'd get with pthread_create(). > Only difference is that they never return to userspace. > Great! Thanks for clarifying. > >>> In theory, it is possible, i.e. from io_uring_enter syscall. But I > >>> don't know the implementation details of io_uring, hence asking the > >>> expert in this list. > >> > >> Right, if the IO is done inline, then it won't make a difference if eg > >> read(2) is used or IORING_OP_READ (or similar) with io_uring. > >> > > Can you please clarify what "IO is done inline" means ? i.e. are there > > cases that are not inline ? > > I mean if the execution of it ends up being app -> io_uring_enter() -> > do io. For some operations, you could end up with: > > io_uring_enter() -> punt to io_wq > io_wq -> do io > > either implicitly because the "do io" operation doesn't support > nonblocking issue (or ran out of resrouces), or explicitly if you set > IOSQE_ASYNC in the SQE you submitted. > Perfect. Thanks! -Jeff Xu
