summaryrefslogtreecommitdiff
path: root/scripts/lib/kdoc/kdoc_files.py
diff options
context:
space:
mode:
authorFengnan Chang <changfengnan@bytedance.com>2025-08-13 20:02:14 +0800
committerJens Axboe <axboe@kernel.dk>2025-08-13 06:31:10 -0600
commit9d83e1f05c98bab5de350bef89177e2be8b34db0 (patch)
treea44a9cec214f9a6376003f461146dc52ee6c57b0 /scripts/lib/kdoc/kdoc_files.py
parent41b70df5b38bc80967d2e0ed55cc3c3896bba781 (diff)
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>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_files.py')
0 files changed, 0 insertions, 0 deletions