io_uring/io-wq: add check free worker before create new worker io_uring-6.17 io_uring-6.17-20250815
authorFengnan Chang <changfengnan@bytedance.com>
Wed, 13 Aug 2025 12:02:14 +0000 (20:02 +0800)
committerJens Axboe <axboe@kernel.dk>
Wed, 13 Aug 2025 12:31:10 +0000 (06:31 -0600)
commit9d83e1f05c98bab5de350bef89177e2be8b34db0
treea44a9cec214f9a6376003f461146dc52ee6c57b0
parent41b70df5b38bc80967d2e0ed55cc3c3896bba781
io_uring/io-wq: add check free worker before create new worker

After commit 0b2b066f8a85 ("io_uring/io-wq: only create a new worker
if it can make progress"), in our produce environment, we still
observe that part of io_worker threads keeps creating and destroying.
After analysis, it was confirmed that this was due to a more complex
scenario involving a large number of fsync operations, which can be
abstracted as frequent write + fsync operations on multiple files in
a single uring instance. Since write is a hash operation while fsync
is not, and fsync is likely to be suspended during execution, the
action of checking the hash value in
io_wqe_dec_running cannot handle such scenarios.
Similarly, if hash-based work and non-hash-based work are sent at the
same time, similar issues are likely to occur.
Returning to the starting point of the issue, when a new work
arrives, io_wq_enqueue may wake up free worker A, while
io_wq_dec_running may create worker B. Ultimately, only one of A and
B can obtain and process the task, leaving the other in an idle
state. In the end, the issue is caused by inconsistent logic in the
checks performed by io_wq_enqueue and io_wq_dec_running.
Therefore, the problem can be resolved by checking for available
workers in io_wq_dec_running.

Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
Reviewed-by: Diangang Li <lidiangang@bytedance.com>
Link: https://lore.kernel.org/r/20250813120214.18729-1-changfengnan@bytedance.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
io_uring/io-wq.c