2019-10-22 10:25:58 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/*
|
|
|
|
|
* Basic worker thread pool for io_uring
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2019 Jens Axboe
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
|
#include <linux/sched/signal.h>
|
|
|
|
|
#include <linux/percpu.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/rculist_nulls.h>
|
2020-10-22 09:02:50 -06:00
|
|
|
#include <linux/cpu.h>
|
2024-09-10 19:11:56 +02:00
|
|
|
#include <linux/cpuset.h>
|
2022-02-09 12:47:08 -06:00
|
|
|
#include <linux/task_work.h>
|
2021-02-16 19:46:48 -05:00
|
|
|
#include <linux/audit.h>
|
2023-03-10 12:11:07 -08:00
|
|
|
#include <linux/mmu_context.h>
|
2026-01-21 10:40:33 -07:00
|
|
|
#include <linux/sched/sysctl.h>
|
2021-09-13 17:44:15 +02:00
|
|
|
#include <uapi/linux/io_uring.h>
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
#include "io-wq.h"
|
2022-06-21 10:09:01 +01:00
|
|
|
#include "slist.h"
|
2022-06-21 10:09:02 +01:00
|
|
|
#include "io_uring.h"
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
#define WORKER_IDLE_TIMEOUT (5 * HZ)
|
2024-07-10 18:58:17 +01:00
|
|
|
#define WORKER_INIT_LIMIT 3
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
enum {
|
2024-05-07 10:00:01 -07:00
|
|
|
IO_WORKER_F_UP = 0, /* up and active */
|
|
|
|
|
IO_WORKER_F_RUNNING = 1, /* account as running */
|
|
|
|
|
IO_WORKER_F_FREE = 2, /* worker on free list */
|
2019-10-22 10:25:58 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
IO_WQ_BIT_EXIT = 0, /* wq exiting */
|
2026-02-02 22:37:53 +08:00
|
|
|
IO_WQ_BIT_EXIT_ON_IDLE = 1, /* allow all workers to exit on idle */
|
2019-10-22 10:25:58 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum {
|
2021-08-31 13:57:32 -06:00
|
|
|
IO_ACCT_STALLED_BIT = 0, /* stalled on hash */
|
2019-10-22 10:25:58 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
2023-03-21 22:16:28 -03:00
|
|
|
* One for each thread in a wq pool
|
2019-10-22 10:25:58 -06:00
|
|
|
*/
|
|
|
|
|
struct io_worker {
|
|
|
|
|
refcount_t ref;
|
2024-05-07 10:00:01 -07:00
|
|
|
unsigned long flags;
|
2019-10-22 10:25:58 -06:00
|
|
|
struct hlist_nulls_node nulls_node;
|
2019-11-13 13:54:49 -07:00
|
|
|
struct list_head all_list;
|
2019-10-22 10:25:58 -06:00
|
|
|
struct task_struct *task;
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq;
|
2025-01-28 14:39:21 +01:00
|
|
|
struct io_wq_acct *acct;
|
2019-11-13 09:43:34 -07:00
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
struct io_wq_work *cur_work;
|
2022-01-18 19:13:43 -07:00
|
|
|
raw_spinlock_t lock;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-02-23 19:59:06 -07:00
|
|
|
struct completion ref_done;
|
|
|
|
|
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
unsigned long create_state;
|
|
|
|
|
struct callback_head create_work;
|
2024-07-10 18:58:17 +01:00
|
|
|
int init_retries;
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
union {
|
|
|
|
|
struct rcu_head rcu;
|
io-wq: backoff when retrying worker creation
When io_uring submission goes async for the first time on a given task,
we'll try to create a worker thread to handle the submission. Creating
this worker thread can fail due to various transient conditions, such as
an outstanding signal in the forking thread, so we have retry logic with
a limit of 3 retries. However, this retry logic appears to be too
aggressive/fast - we've observed a thread blowing through the retry
limit while having the same outstanding signal the whole time. Here's an
excerpt of some tracing that demonstrates the issue:
First, signal 26 is generated for the process. It ends up getting routed
to thread 92942.
0) cbd-92284 /* signal_generate: sig=26 errno=0 code=-2 comm=psblkdASD pid=92934 grp=1 res=0 */
This causes create_io_thread in the signalled thread to fail with
ERESTARTNOINTR, and thus a retry is queued.
13) task_th-92942 /* io_uring_queue_async_work: ring 000000007325c9ae, request 0000000080c96d8e, user_data 0x0, opcode URING_CMD, flags 0x8240001, normal queue, work 000000006e96dd3f */
13) task_th-92942 io_wq_enqueue() {
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 io_wq_activate_free_worker();
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 create_io_worker() {
13) task_th-92942 __kmalloc_cache_noprof();
13) task_th-92942 __init_swait_queue_head();
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
...
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_io_worker+0x8a/0x1a0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 queue_work_on() {
...
The CPU is then handed to a kworker to process the queued retry:
------------------------------------------
13) task_th-92942 => kworker-54154
------------------------------------------
13) kworker-54154 io_workqueue_create() {
13) kworker-54154 io_queue_worker_create() {
13) kworker-54154 task_work_add() {
13) kworker-54154 wake_up_state() {
13) kworker-54154 try_to_wake_up() {
13) kworker-54154 _raw_spin_lock_irqsave();
13) kworker-54154 _raw_spin_unlock_irqrestore();
13) kworker-54154 } /* try_to_wake_up */
13) kworker-54154 } /* wake_up_state */
13) kworker-54154 kick_process();
13) kworker-54154 } /* task_work_add */
13) kworker-54154 } /* io_queue_worker_create */
13) kworker-54154 } /* io_workqueue_create */
And then we immediately switch back to the original task to try creating
a worker again. This fails, because the original task still hasn't
handled its signal.
-----------------------------------------
13) kworker-54154 => task_th-92942
------------------------------------------
13) task_th-92942 create_worker_cont() {
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
13) task_th-92942 } /* kprobe_ftrace_handler */
13) task_th-92942 create_io_thread() {
13) task_th-92942 copy_process() {
13) task_th-92942 task_active_pid_ns();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 recalc_sigpending();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_worker_cont+0x35/0x1b0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 io_worker_release();
13) task_th-92942 queue_work_on() {
13) task_th-92942 clear_pending_if_disabled();
13) task_th-92942 __queue_work() {
13) task_th-92942 } /* __queue_work */
13) task_th-92942 } /* queue_work_on */
13) task_th-92942 } /* create_worker_cont */
The pattern repeats another couple times until we blow through the retry
counter, at which point we give up. All outstanding work is canceled,
and the io_uring command which triggered all this is failed with
ECANCELED:
13) task_th-92942 io_acct_cancel_pending_work() {
...
13) task_th-92942 /* io_uring_complete: ring 000000007325c9ae, req 0000000080c96d8e, user_data 0x0, result -125, cflags 0x0 extra1 0 extra2 0 */
Finally, the task gets around to processing its outstanding signal 26,
but it's too late.
13) task_th-92942 /* signal_deliver: sig=26 errno=0 code=-2 sa_handler=59566a0 sa_flags=14000000 */
Try to address this issue by adding a small scaling delay when retrying
worker creation. This should give the forking thread time to handle its
signal in the above case. This isn't a particularly satisfying solution,
as sufficiently paradoxical scheduling would still have us hitting the
same issue, and I'm open to suggestions for something better. But this
is likely to prevent this (already rare) issue from hitting in practice.
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Link: https://lore.kernel.org/r/20250208-wq_retry-v2-1-4f6f5041d303@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-08 13:42:13 -07:00
|
|
|
struct delayed_work work;
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
};
|
2019-10-22 10:25:58 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#if BITS_PER_LONG == 64
|
|
|
|
|
#define IO_WQ_HASH_ORDER 6
|
|
|
|
|
#else
|
|
|
|
|
#define IO_WQ_HASH_ORDER 5
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-03-23 22:57:22 +03:00
|
|
|
#define IO_WQ_NR_HASH_BUCKETS (1u << IO_WQ_HASH_ORDER)
|
|
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct {
|
2025-01-28 14:39:22 +01:00
|
|
|
/**
|
|
|
|
|
* Protects access to the worker lists.
|
|
|
|
|
*/
|
|
|
|
|
raw_spinlock_t workers_lock;
|
|
|
|
|
|
2019-11-07 11:41:16 -07:00
|
|
|
unsigned nr_workers;
|
|
|
|
|
unsigned max_workers;
|
|
|
|
|
atomic_t nr_running;
|
2025-01-28 14:39:22 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* The list of free workers. Protected by #workers_lock
|
|
|
|
|
* (write) and RCU (read).
|
|
|
|
|
*/
|
|
|
|
|
struct hlist_nulls_head free_list;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* The list of all workers. Protected by #workers_lock
|
|
|
|
|
* (write) and RCU (read).
|
|
|
|
|
*/
|
|
|
|
|
struct list_head all_list;
|
|
|
|
|
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spinlock_t lock;
|
2021-08-31 13:57:32 -06:00
|
|
|
struct io_wq_work_list work_list;
|
|
|
|
|
unsigned long flags;
|
2019-11-07 11:41:16 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
IO_WQ_ACCT_BOUND,
|
|
|
|
|
IO_WQ_ACCT_UNBOUND,
|
2021-08-31 13:57:32 -06:00
|
|
|
IO_WQ_ACCT_NR,
|
2019-11-07 11:41:16 -07:00
|
|
|
};
|
|
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
/*
|
|
|
|
|
* Per io_wq state
|
|
|
|
|
*/
|
|
|
|
|
struct io_wq {
|
|
|
|
|
unsigned long state;
|
|
|
|
|
|
2021-02-19 12:33:30 -07:00
|
|
|
struct io_wq_hash *hash;
|
|
|
|
|
|
2021-02-26 09:47:20 -07:00
|
|
|
atomic_t worker_refs;
|
|
|
|
|
struct completion worker_done;
|
|
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
struct hlist_node cpuhp_node;
|
2021-02-16 14:15:30 -07:00
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
struct task_struct *task;
|
2021-06-14 02:36:12 +01:00
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct acct[IO_WQ_ACCT_NR];
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
struct wait_queue_entry wait;
|
|
|
|
|
|
|
|
|
|
struct io_wq_work *hash_tail[IO_WQ_NR_HASH_BUCKETS];
|
|
|
|
|
|
|
|
|
|
cpumask_var_t cpu_mask;
|
2019-10-22 10:25:58 -06:00
|
|
|
};
|
|
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
static enum cpuhp_state io_wq_online;
|
|
|
|
|
|
2021-03-03 15:47:04 -07:00
|
|
|
struct io_cb_cancel_data {
|
|
|
|
|
work_cancel_fn *fn;
|
|
|
|
|
void *data;
|
|
|
|
|
int nr_running;
|
|
|
|
|
int nr_pending;
|
|
|
|
|
bool cancel_all;
|
|
|
|
|
};
|
|
|
|
|
|
2025-01-28 14:39:21 +01:00
|
|
|
static bool create_io_worker(struct io_wq *wq, struct io_wq_acct *acct);
|
2023-03-21 22:16:28 -03:00
|
|
|
static void io_wq_dec_running(struct io_worker *worker);
|
|
|
|
|
static bool io_acct_cancel_pending_work(struct io_wq *wq,
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct,
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
struct io_cb_cancel_data *match);
|
2021-10-29 13:11:33 +01:00
|
|
|
static void create_worker_cb(struct callback_head *cb);
|
2021-12-10 08:29:30 -07:00
|
|
|
static void io_wq_cancel_tw_create(struct io_wq *wq);
|
2021-03-03 15:47:04 -07:00
|
|
|
|
2025-05-23 06:04:29 -06:00
|
|
|
static inline unsigned int __io_get_work_hash(unsigned int work_flags)
|
|
|
|
|
{
|
|
|
|
|
return work_flags >> IO_WQ_HASH_SHIFT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline unsigned int io_get_work_hash(struct io_wq_work *work)
|
|
|
|
|
{
|
|
|
|
|
return __io_get_work_hash(atomic_read(&work->flags));
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
static bool io_worker_get(struct io_worker *worker)
|
|
|
|
|
{
|
|
|
|
|
return refcount_inc_not_zero(&worker->ref);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void io_worker_release(struct io_worker *worker)
|
|
|
|
|
{
|
|
|
|
|
if (refcount_dec_and_test(&worker->ref))
|
2021-02-23 19:59:06 -07:00
|
|
|
complete(&worker->ref_done);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
static inline struct io_wq_acct *io_get_acct(struct io_wq *wq, bool bound)
|
2021-03-22 01:58:28 +00:00
|
|
|
{
|
2023-03-21 22:16:27 -03:00
|
|
|
return &wq->acct[bound ? IO_WQ_ACCT_BOUND : IO_WQ_ACCT_UNBOUND];
|
2021-03-22 01:58:28 +00:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
static inline struct io_wq_acct *io_work_get_acct(struct io_wq *wq,
|
2025-01-28 14:39:23 +01:00
|
|
|
unsigned int work_flags)
|
2019-11-07 11:41:16 -07:00
|
|
|
{
|
2025-01-28 14:39:23 +01:00
|
|
|
return io_get_acct(wq, !(work_flags & IO_WQ_WORK_UNBOUND));
|
2019-11-07 11:41:16 -07:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
static inline struct io_wq_acct *io_wq_get_acct(struct io_worker *worker)
|
2019-11-07 11:41:16 -07:00
|
|
|
{
|
2025-01-28 14:39:21 +01:00
|
|
|
return worker->acct;
|
2019-11-07 11:41:16 -07:00
|
|
|
}
|
|
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
static void io_worker_ref_put(struct io_wq *wq)
|
|
|
|
|
{
|
|
|
|
|
if (atomic_dec_and_test(&wq->worker_refs))
|
|
|
|
|
complete(&wq->worker_done);
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-07 13:50:07 +01:00
|
|
|
bool io_wq_worker_stopped(void)
|
|
|
|
|
{
|
|
|
|
|
struct io_worker *worker = current->worker_private;
|
|
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!io_wq_current_is_worker()))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
return test_bit(IO_WQ_BIT_EXIT, &worker->wq->state);
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-29 13:11:33 +01:00
|
|
|
static void io_worker_cancel_cb(struct io_worker *worker)
|
|
|
|
|
{
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = io_wq_get_acct(worker);
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = worker->wq;
|
2021-10-29 13:11:33 +01:00
|
|
|
|
|
|
|
|
atomic_dec(&acct->nr_running);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2021-10-29 13:11:33 +01:00
|
|
|
acct->nr_workers--;
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-10-29 13:11:33 +01:00
|
|
|
io_worker_ref_put(wq);
|
|
|
|
|
clear_bit_unlock(0, &worker->create_state);
|
|
|
|
|
io_worker_release(worker);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool io_task_worker_match(struct callback_head *cb, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct io_worker *worker;
|
|
|
|
|
|
|
|
|
|
if (cb->func != create_worker_cb)
|
|
|
|
|
return false;
|
|
|
|
|
worker = container_of(cb, struct io_worker, create_work);
|
|
|
|
|
return worker == data;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
static void io_worker_exit(struct io_worker *worker)
|
|
|
|
|
{
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = worker->wq;
|
2025-01-28 14:39:22 +01:00
|
|
|
struct io_wq_acct *acct = io_wq_get_acct(worker);
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-10-29 13:11:33 +01:00
|
|
|
while (1) {
|
|
|
|
|
struct callback_head *cb = task_work_cancel_match(wq->task,
|
|
|
|
|
io_task_worker_match, worker);
|
|
|
|
|
|
|
|
|
|
if (!cb)
|
|
|
|
|
break;
|
|
|
|
|
io_worker_cancel_cb(worker);
|
|
|
|
|
}
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-10-23 12:13:55 +01:00
|
|
|
io_worker_release(worker);
|
2021-02-23 19:59:06 -07:00
|
|
|
wait_for_completion(&worker->ref_done);
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2024-05-07 10:00:01 -07:00
|
|
|
if (test_bit(IO_WORKER_F_FREE, &worker->flags))
|
2021-02-16 18:00:55 -07:00
|
|
|
hlist_nulls_del_rcu(&worker->nulls_node);
|
2019-11-13 13:54:49 -07:00
|
|
|
list_del_rcu(&worker->all_list);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_dec_running(worker);
|
2023-06-13 19:26:55 -06:00
|
|
|
/*
|
|
|
|
|
* this worker is a goner, clear ->worker_private to avoid any
|
|
|
|
|
* inc/dec running calls that could happen as part of exit from
|
|
|
|
|
* touching 'worker'.
|
|
|
|
|
*/
|
|
|
|
|
current->worker_private = NULL;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2019-11-02 15:55:01 +08:00
|
|
|
kfree_rcu(worker, rcu);
|
2023-03-21 22:16:28 -03:00
|
|
|
io_worker_ref_put(wq);
|
2021-03-04 12:39:36 -07:00
|
|
|
do_exit(0);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
2023-08-09 12:59:40 -06:00
|
|
|
static inline bool __io_acct_run_queue(struct io_wq_acct *acct)
|
2019-11-07 11:41:16 -07:00
|
|
|
{
|
2023-08-09 12:59:40 -06:00
|
|
|
return !test_bit(IO_ACCT_STALLED_BIT, &acct->flags) &&
|
|
|
|
|
!wq_list_empty(&acct->work_list);
|
|
|
|
|
}
|
2022-02-06 17:52:40 +08:00
|
|
|
|
2023-08-09 12:59:40 -06:00
|
|
|
/*
|
|
|
|
|
* If there's work to do, returns true with acct->lock acquired. If not,
|
|
|
|
|
* returns false with no lock held.
|
|
|
|
|
*/
|
|
|
|
|
static inline bool io_acct_run_queue(struct io_wq_acct *acct)
|
|
|
|
|
__acquires(&acct->lock)
|
|
|
|
|
{
|
2022-02-06 17:52:40 +08:00
|
|
|
raw_spin_lock(&acct->lock);
|
2023-08-09 12:59:40 -06:00
|
|
|
if (__io_acct_run_queue(acct))
|
|
|
|
|
return true;
|
2022-02-06 17:52:40 +08:00
|
|
|
|
2023-08-09 12:59:40 -06:00
|
|
|
raw_spin_unlock(&acct->lock);
|
|
|
|
|
return false;
|
2019-11-07 11:41:16 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Check head of free list for an available worker. If one isn't available,
|
2021-03-08 09:37:51 -07:00
|
|
|
* caller must create one.
|
2019-11-07 11:41:16 -07:00
|
|
|
*/
|
2025-01-28 14:39:22 +01:00
|
|
|
static bool io_acct_activate_free_worker(struct io_wq_acct *acct)
|
2019-11-07 11:41:16 -07:00
|
|
|
__must_hold(RCU)
|
|
|
|
|
{
|
|
|
|
|
struct hlist_nulls_node *n;
|
|
|
|
|
struct io_worker *worker;
|
|
|
|
|
|
2021-08-03 09:14:35 -06:00
|
|
|
/*
|
|
|
|
|
* Iterate free_list and see if we can find an idle worker to
|
|
|
|
|
* activate. If a given worker is on the free_list but in the process
|
|
|
|
|
* of exiting, keep trying.
|
|
|
|
|
*/
|
2025-01-28 14:39:22 +01:00
|
|
|
hlist_nulls_for_each_entry_rcu(worker, n, &acct->free_list, nulls_node) {
|
2021-08-03 09:14:35 -06:00
|
|
|
if (!io_worker_get(worker))
|
|
|
|
|
continue;
|
2023-08-09 13:07:54 -06:00
|
|
|
/*
|
|
|
|
|
* If the worker is already running, it's either already
|
|
|
|
|
* starting work or finishing work. In either case, if it does
|
|
|
|
|
* to go sleep, we'll kick off a new task for this work anyway.
|
|
|
|
|
*/
|
|
|
|
|
wake_up_process(worker->task);
|
2019-11-07 11:41:16 -07:00
|
|
|
io_worker_release(worker);
|
2023-08-09 13:07:54 -06:00
|
|
|
return true;
|
2019-11-07 11:41:16 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We need a worker. If we find a free one, we're good. If not, and we're
|
2021-03-08 09:37:51 -07:00
|
|
|
* below the max number of workers, create one.
|
2019-11-07 11:41:16 -07:00
|
|
|
*/
|
2023-03-21 22:16:28 -03:00
|
|
|
static bool io_wq_create_worker(struct io_wq *wq, struct io_wq_acct *acct)
|
2019-11-07 11:41:16 -07:00
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Most likely an attempt to queue unbounded work on an io_wq that
|
|
|
|
|
* wasn't setup with any unbounded workers.
|
|
|
|
|
*/
|
2021-06-17 18:13:59 +01:00
|
|
|
if (unlikely(!acct->max_workers))
|
|
|
|
|
pr_warn_once("io-wq is not configured for unbound workers");
|
2019-11-07 11:41:16 -07:00
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2021-10-19 20:31:26 +01:00
|
|
|
if (acct->nr_workers >= acct->max_workers) {
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-09-12 03:40:50 +08:00
|
|
|
return true;
|
2021-08-30 11:55:22 -06:00
|
|
|
}
|
2021-09-12 03:40:50 +08:00
|
|
|
acct->nr_workers++;
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-09-12 03:40:50 +08:00
|
|
|
atomic_inc(&acct->nr_running);
|
2023-03-21 22:16:28 -03:00
|
|
|
atomic_inc(&wq->worker_refs);
|
2025-01-28 14:39:21 +01:00
|
|
|
return create_io_worker(wq, acct);
|
2019-11-07 11:41:16 -07:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static void io_wq_inc_running(struct io_worker *worker)
|
2019-11-07 11:41:16 -07:00
|
|
|
{
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = io_wq_get_acct(worker);
|
2019-11-07 11:41:16 -07:00
|
|
|
|
|
|
|
|
atomic_inc(&acct->nr_running);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
static void create_worker_cb(struct callback_head *cb)
|
|
|
|
|
{
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
struct io_worker *worker;
|
2021-03-08 09:37:51 -07:00
|
|
|
struct io_wq *wq;
|
2023-03-21 22:16:28 -03:00
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct;
|
2025-09-12 02:06:09 +02:00
|
|
|
bool activated_free_worker, do_create = false;
|
2021-03-08 09:37:51 -07:00
|
|
|
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
worker = container_of(cb, struct io_worker, create_work);
|
2023-03-21 22:16:28 -03:00
|
|
|
wq = worker->wq;
|
2025-01-28 14:39:21 +01:00
|
|
|
acct = worker->acct;
|
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>
2025-08-13 20:02:14 +08:00
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2025-09-12 02:06:09 +02:00
|
|
|
activated_free_worker = io_acct_activate_free_worker(acct);
|
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>
2025-08-13 20:02:14 +08:00
|
|
|
rcu_read_unlock();
|
2025-09-12 02:06:09 +02:00
|
|
|
if (activated_free_worker)
|
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>
2025-08-13 20:02:14 +08:00
|
|
|
goto no_need_create;
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
|
2021-08-08 21:54:33 +08:00
|
|
|
if (acct->nr_workers < acct->max_workers) {
|
2021-08-05 18:05:38 +08:00
|
|
|
acct->nr_workers++;
|
2021-08-08 21:54:33 +08:00
|
|
|
do_create = true;
|
|
|
|
|
}
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-08-08 21:54:33 +08:00
|
|
|
if (do_create) {
|
2025-01-28 14:39:21 +01:00
|
|
|
create_io_worker(wq, acct);
|
2021-08-08 21:54:33 +08:00
|
|
|
} else {
|
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>
2025-08-13 20:02:14 +08:00
|
|
|
no_need_create:
|
2021-08-08 21:54:33 +08:00
|
|
|
atomic_dec(&acct->nr_running);
|
|
|
|
|
io_worker_ref_put(wq);
|
|
|
|
|
}
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
clear_bit_unlock(0, &worker->create_state);
|
|
|
|
|
io_worker_release(worker);
|
2021-03-08 09:37:51 -07:00
|
|
|
}
|
|
|
|
|
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
static bool io_queue_worker_create(struct io_worker *worker,
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct,
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
task_work_func_t func)
|
2021-03-08 09:37:51 -07:00
|
|
|
{
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = worker->wq;
|
2021-03-08 09:37:51 -07:00
|
|
|
|
|
|
|
|
/* raced with exit, just ignore create call */
|
|
|
|
|
if (test_bit(IO_WQ_BIT_EXIT, &wq->state))
|
|
|
|
|
goto fail;
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
if (!io_worker_get(worker))
|
|
|
|
|
goto fail;
|
|
|
|
|
/*
|
|
|
|
|
* create_state manages ownership of create_work/index. We should
|
|
|
|
|
* only need one entry per worker, as the worker going to sleep
|
|
|
|
|
* will trigger the condition, and waking will clear it once it
|
|
|
|
|
* runs the task_work.
|
|
|
|
|
*/
|
|
|
|
|
if (test_bit(0, &worker->create_state) ||
|
|
|
|
|
test_and_set_bit_lock(0, &worker->create_state))
|
|
|
|
|
goto fail_release;
|
2021-03-08 09:37:51 -07:00
|
|
|
|
2021-12-10 08:29:30 -07:00
|
|
|
atomic_inc(&wq->worker_refs);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
init_task_work(&worker->create_work, func);
|
2021-12-10 08:29:30 -07:00
|
|
|
if (!task_work_add(wq->task, &worker->create_work, TWA_SIGNAL)) {
|
|
|
|
|
/*
|
|
|
|
|
* EXIT may have been set after checking it above, check after
|
|
|
|
|
* adding the task_work and remove any creation item if it is
|
|
|
|
|
* now set. wq exit does that too, but we can have added this
|
|
|
|
|
* work item after we canceled in io_wq_exit_workers().
|
|
|
|
|
*/
|
|
|
|
|
if (test_bit(IO_WQ_BIT_EXIT, &wq->state))
|
|
|
|
|
io_wq_cancel_tw_create(wq);
|
|
|
|
|
io_worker_ref_put(wq);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
return true;
|
2021-12-10 08:29:30 -07:00
|
|
|
}
|
|
|
|
|
io_worker_ref_put(wq);
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
clear_bit_unlock(0, &worker->create_state);
|
|
|
|
|
fail_release:
|
|
|
|
|
io_worker_release(worker);
|
2021-03-08 09:37:51 -07:00
|
|
|
fail:
|
|
|
|
|
atomic_dec(&acct->nr_running);
|
|
|
|
|
io_worker_ref_put(wq);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
return false;
|
2021-03-08 09:37:51 -07:00
|
|
|
}
|
|
|
|
|
|
2025-05-23 06:08:49 -06:00
|
|
|
/* Defer if current and next work are both hashed to the same chain */
|
|
|
|
|
static bool io_wq_hash_defer(struct io_wq_work *work, struct io_wq_acct *acct)
|
|
|
|
|
{
|
|
|
|
|
unsigned int hash, work_flags;
|
|
|
|
|
struct io_wq_work *next;
|
|
|
|
|
|
|
|
|
|
lockdep_assert_held(&acct->lock);
|
|
|
|
|
|
|
|
|
|
work_flags = atomic_read(&work->flags);
|
|
|
|
|
if (!__io_wq_is_hashed(work_flags))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/* should not happen, io_acct_run_queue() said we had work */
|
|
|
|
|
if (wq_list_empty(&acct->work_list))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
hash = __io_get_work_hash(work_flags);
|
|
|
|
|
next = container_of(acct->work_list.first, struct io_wq_work, list);
|
|
|
|
|
work_flags = atomic_read(&next->flags);
|
|
|
|
|
if (!__io_wq_is_hashed(work_flags))
|
|
|
|
|
return false;
|
|
|
|
|
return hash == __io_get_work_hash(work_flags);
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static void io_wq_dec_running(struct io_worker *worker)
|
2019-11-07 11:41:16 -07:00
|
|
|
{
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = io_wq_get_acct(worker);
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = worker->wq;
|
2019-11-07 11:41:16 -07:00
|
|
|
|
2024-05-07 10:00:01 -07:00
|
|
|
if (!test_bit(IO_WORKER_F_UP, &worker->flags))
|
2021-03-08 09:37:51 -07:00
|
|
|
return;
|
|
|
|
|
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
if (!atomic_dec_and_test(&acct->nr_running))
|
|
|
|
|
return;
|
2025-05-23 06:05:37 -06:00
|
|
|
if (!worker->cur_work)
|
|
|
|
|
return;
|
2022-02-06 17:52:40 +08:00
|
|
|
if (!io_acct_run_queue(acct))
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
return;
|
2025-05-23 06:08:49 -06:00
|
|
|
if (io_wq_hash_defer(worker->cur_work, acct)) {
|
|
|
|
|
raw_spin_unlock(&acct->lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
|
2023-08-09 12:59:40 -06:00
|
|
|
raw_spin_unlock(&acct->lock);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
atomic_inc(&acct->nr_running);
|
2023-03-21 22:16:28 -03:00
|
|
|
atomic_inc(&wq->worker_refs);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
io_queue_worker_create(worker, acct, create_worker_cb);
|
2019-11-07 11:41:16 -07:00
|
|
|
}
|
|
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
/*
|
|
|
|
|
* Worker will start processing some work. Move it to the busy list, if
|
|
|
|
|
* it's currently on the freelist
|
|
|
|
|
*/
|
2025-01-28 14:39:22 +01:00
|
|
|
static void __io_worker_busy(struct io_wq_acct *acct, struct io_worker *worker)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2024-05-07 10:00:01 -07:00
|
|
|
if (test_bit(IO_WORKER_F_FREE, &worker->flags)) {
|
|
|
|
|
clear_bit(IO_WORKER_F_FREE, &worker->flags);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2019-10-22 10:25:58 -06:00
|
|
|
hlist_nulls_del_init_rcu(&worker->nulls_node);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2023-03-27 13:10:21 -06:00
|
|
|
* No work, worker going to sleep. Move to freelist.
|
2019-10-22 10:25:58 -06:00
|
|
|
*/
|
2025-01-28 14:39:22 +01:00
|
|
|
static void __io_worker_idle(struct io_wq_acct *acct, struct io_worker *worker)
|
|
|
|
|
__must_hold(acct->workers_lock)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2024-05-07 10:00:01 -07:00
|
|
|
if (!test_bit(IO_WORKER_F_FREE, &worker->flags)) {
|
|
|
|
|
set_bit(IO_WORKER_F_FREE, &worker->flags);
|
2025-01-28 14:39:22 +01:00
|
|
|
hlist_nulls_add_head_rcu(&worker->nulls_node, &acct->free_list);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static bool io_wait_on_hash(struct io_wq *wq, unsigned int hash)
|
2021-02-19 12:33:30 -07:00
|
|
|
{
|
2021-11-11 17:32:53 -07:00
|
|
|
bool ret = false;
|
2021-02-19 12:33:30 -07:00
|
|
|
|
2021-08-31 06:57:25 -06:00
|
|
|
spin_lock_irq(&wq->hash->wait.lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
if (list_empty(&wq->wait.entry)) {
|
|
|
|
|
__add_wait_queue(&wq->hash->wait, &wq->wait);
|
2021-02-19 12:33:30 -07:00
|
|
|
if (!test_bit(hash, &wq->hash->map)) {
|
|
|
|
|
__set_current_state(TASK_RUNNING);
|
2023-03-21 22:16:28 -03:00
|
|
|
list_del_init(&wq->wait.entry);
|
2021-11-11 17:32:53 -07:00
|
|
|
ret = true;
|
2021-02-19 12:33:30 -07:00
|
|
|
}
|
|
|
|
|
}
|
2021-08-31 06:57:25 -06:00
|
|
|
spin_unlock_irq(&wq->hash->wait.lock);
|
2021-11-11 17:32:53 -07:00
|
|
|
return ret;
|
2021-02-19 12:33:30 -07:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:27 -03:00
|
|
|
static struct io_wq_work *io_get_next_work(struct io_wq_acct *acct,
|
2025-01-28 14:39:25 +01:00
|
|
|
struct io_wq *wq)
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
__must_hold(acct->lock)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2019-11-26 11:59:32 -07:00
|
|
|
struct io_wq_work_node *node, *prev;
|
2020-03-23 22:57:22 +03:00
|
|
|
struct io_wq_work *work, *tail;
|
2021-02-19 12:33:30 -07:00
|
|
|
unsigned int stall_hash = -1U;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-08-31 13:57:32 -06:00
|
|
|
wq_list_for_each(node, prev, &acct->work_list) {
|
2025-01-28 14:39:23 +01:00
|
|
|
unsigned int work_flags;
|
2021-02-19 12:33:30 -07:00
|
|
|
unsigned int hash;
|
|
|
|
|
|
2019-11-26 11:59:32 -07:00
|
|
|
work = container_of(node, struct io_wq_work, list);
|
|
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
/* not hashed, can run anytime */
|
2025-01-28 14:39:23 +01:00
|
|
|
work_flags = atomic_read(&work->flags);
|
|
|
|
|
if (!__io_wq_is_hashed(work_flags)) {
|
2021-08-31 13:57:32 -06:00
|
|
|
wq_list_del(&acct->work_list, node, prev);
|
2019-10-22 10:25:58 -06:00
|
|
|
return work;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-28 14:39:23 +01:00
|
|
|
hash = __io_get_work_hash(work_flags);
|
2021-02-19 12:33:30 -07:00
|
|
|
/* all items with this hash lie in [work, tail] */
|
2023-03-21 22:16:28 -03:00
|
|
|
tail = wq->hash_tail[hash];
|
2021-02-19 12:33:30 -07:00
|
|
|
|
|
|
|
|
/* hashed, can run if not already running */
|
2023-03-21 22:16:28 -03:00
|
|
|
if (!test_and_set_bit(hash, &wq->hash->map)) {
|
|
|
|
|
wq->hash_tail[hash] = NULL;
|
2021-08-31 13:57:32 -06:00
|
|
|
wq_list_cut(&acct->work_list, &tail->list, prev);
|
2019-10-22 10:25:58 -06:00
|
|
|
return work;
|
|
|
|
|
}
|
2021-02-19 12:33:30 -07:00
|
|
|
if (stall_hash == -1U)
|
|
|
|
|
stall_hash = hash;
|
|
|
|
|
/* fast forward to a next hash, for-each will fix up @prev */
|
|
|
|
|
node = &tail->list;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (stall_hash != -1U) {
|
2021-11-11 17:32:53 -07:00
|
|
|
bool unstalled;
|
|
|
|
|
|
2021-08-31 13:53:00 -06:00
|
|
|
/*
|
|
|
|
|
* Set this before dropping the lock to avoid racing with new
|
|
|
|
|
* work being added and clearing the stalled bit.
|
|
|
|
|
*/
|
2021-08-31 13:57:32 -06:00
|
|
|
set_bit(IO_ACCT_STALLED_BIT, &acct->flags);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_unlock(&acct->lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
unstalled = io_wait_on_hash(wq, stall_hash);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_lock(&acct->lock);
|
2021-11-11 17:32:53 -07:00
|
|
|
if (unstalled) {
|
|
|
|
|
clear_bit(IO_ACCT_STALLED_BIT, &acct->flags);
|
2023-03-21 22:16:28 -03:00
|
|
|
if (wq_has_sleeper(&wq->hash->wait))
|
|
|
|
|
wake_up(&wq->hash->wait);
|
2021-11-11 17:32:53 -07:00
|
|
|
}
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-04 16:14:09 +03:00
|
|
|
static void io_assign_current_work(struct io_worker *worker,
|
|
|
|
|
struct io_wq_work *work)
|
|
|
|
|
{
|
2020-03-14 00:31:03 +03:00
|
|
|
if (work) {
|
2022-06-21 10:09:02 +01:00
|
|
|
io_run_task_work();
|
2020-03-14 00:31:03 +03:00
|
|
|
cond_resched();
|
|
|
|
|
}
|
2020-03-04 16:14:09 +03:00
|
|
|
|
2022-01-18 19:13:43 -07:00
|
|
|
raw_spin_lock(&worker->lock);
|
2020-03-04 16:14:09 +03:00
|
|
|
worker->cur_work = work;
|
2022-01-18 19:13:43 -07:00
|
|
|
raw_spin_unlock(&worker->lock);
|
2020-03-04 16:14:09 +03:00
|
|
|
}
|
|
|
|
|
|
2023-08-09 12:59:40 -06:00
|
|
|
/*
|
|
|
|
|
* Called with acct->lock held, drops it before returning
|
|
|
|
|
*/
|
|
|
|
|
static void io_worker_handle_work(struct io_wq_acct *acct,
|
|
|
|
|
struct io_worker *worker)
|
|
|
|
|
__releases(&acct->lock)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = worker->wq;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
do {
|
io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop
Currently this is checked before running the pending work. Normally this
is quite fine, as work items either end up blocking (which will create a
new worker for other items), or they complete fairly quickly. But syzbot
reports an issue where io-wq takes seemingly forever to exit, and with a
bit of debugging, this turns out to be because it queues a bunch of big
(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't
support ->read_iter(), loop_rw_iter() ends up handling them. Each read
returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
these pending, processing the whole chain can take a long time. Easily
longer than the syzbot uninterruptible sleep timeout of 140 seconds.
This then triggers a complaint off the io-wq exit path:
INFO: task syz.4.135:6326 blocked for more than 143 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5256 [inline]
__schedule+0x1139/0x6150 kernel/sched/core.c:6863
__schedule_loop kernel/sched/core.c:6945 [inline]
schedule+0xe7/0x3a0 kernel/sched/core.c:6960
schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
do_wait_for_common kernel/sched/completion.c:100 [inline]
__wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121
io_wq_exit_workers io_uring/io-wq.c:1328 [inline]
io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356
io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203
io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651
io_uring_files_cancel include/linux/io_uring.h:19 [inline]
do_exit+0x2ce/0x2bd0 kernel/exit.c:911
do_group_exit+0xd3/0x2a0 kernel/exit.c:1112
get_signal+0x2671/0x26d0 kernel/signal.c:3034
arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa02738f749
RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098
RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98
There's really nothing wrong here, outside of processing these reads
will take a LONG time. However, we can speed up the exit by checking the
IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will
exit the ring after queueing up all of these reads. Then once the first
item is processed, io-wq will simply cancel the rest. That should avoid
syzbot running into this complaint again.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/68a2decc.050a0220.e29e5.0099.GAE@google.com/
Reported-by: syzbot+4eb282331cab6d5b6588@syzkaller.appspotmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-20 07:42:50 -07:00
|
|
|
bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state);
|
2020-03-23 22:57:22 +03:00
|
|
|
struct io_wq_work *work;
|
2022-01-19 13:11:58 -07:00
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
/*
|
|
|
|
|
* If we got some work, mark us as busy. If we didn't, but
|
|
|
|
|
* the list isn't empty, it means we stalled on hashed work.
|
|
|
|
|
* Mark us stalled so we don't keep looking for work when we
|
|
|
|
|
* can't make progress, any work completion or insertion will
|
|
|
|
|
* clear the stalled flag.
|
|
|
|
|
*/
|
2025-01-28 14:39:25 +01:00
|
|
|
work = io_get_next_work(acct, wq);
|
2022-01-18 19:23:51 -07:00
|
|
|
if (work) {
|
|
|
|
|
/*
|
|
|
|
|
* Make sure cancelation can find this, even before
|
|
|
|
|
* it becomes the active work. That avoids a window
|
|
|
|
|
* where the work has been removed from our general
|
|
|
|
|
* work list, but isn't yet discoverable as the
|
|
|
|
|
* current work item for this worker.
|
|
|
|
|
*/
|
|
|
|
|
raw_spin_lock(&worker->lock);
|
2024-04-15 22:10:54 -04:00
|
|
|
worker->cur_work = work;
|
2022-01-18 19:23:51 -07:00
|
|
|
raw_spin_unlock(&worker->lock);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
}
|
2024-04-15 22:10:53 -04:00
|
|
|
|
|
|
|
|
raw_spin_unlock(&acct->lock);
|
|
|
|
|
|
|
|
|
|
if (!work)
|
|
|
|
|
break;
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
__io_worker_busy(acct, worker);
|
2024-04-15 22:10:53 -04:00
|
|
|
|
2020-03-04 16:14:10 +03:00
|
|
|
io_assign_current_work(worker, work);
|
2021-02-19 12:33:30 -07:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2019-11-13 09:43:34 -07:00
|
|
|
|
2020-03-04 16:14:09 +03:00
|
|
|
/* handle a whole dependent link */
|
|
|
|
|
do {
|
2021-02-04 13:52:08 +00:00
|
|
|
struct io_wq_work *next_hashed, *linked;
|
2025-01-28 14:39:23 +01:00
|
|
|
unsigned int work_flags = atomic_read(&work->flags);
|
2025-01-28 14:39:24 +01:00
|
|
|
unsigned int hash = __io_wq_is_hashed(work_flags)
|
|
|
|
|
? __io_get_work_hash(work_flags)
|
|
|
|
|
: -1U;
|
2019-12-24 09:14:29 -07:00
|
|
|
|
2020-03-23 22:57:22 +03:00
|
|
|
next_hashed = wq_next_work(work);
|
2021-04-08 01:54:42 +01:00
|
|
|
|
2024-06-13 19:28:27 +00:00
|
|
|
if (do_kill &&
|
2025-01-28 14:39:23 +01:00
|
|
|
(work_flags & IO_WQ_WORK_UNBOUND))
|
2024-06-13 19:28:27 +00:00
|
|
|
atomic_or(IO_WQ_WORK_CANCEL, &work->flags);
|
2025-03-29 10:15:24 -06:00
|
|
|
io_wq_submit_work(work);
|
2021-02-04 13:52:08 +00:00
|
|
|
io_assign_current_work(worker, NULL);
|
2019-11-13 09:43:34 -07:00
|
|
|
|
2025-03-29 10:15:24 -06:00
|
|
|
linked = io_wq_free_work(work);
|
2020-03-23 22:57:22 +03:00
|
|
|
work = next_hashed;
|
|
|
|
|
if (!work && linked && !io_wq_is_hashed(linked)) {
|
|
|
|
|
work = linked;
|
|
|
|
|
linked = NULL;
|
|
|
|
|
}
|
|
|
|
|
io_assign_current_work(worker, work);
|
|
|
|
|
if (linked)
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_enqueue(wq, linked);
|
2020-03-23 22:57:22 +03:00
|
|
|
|
|
|
|
|
if (hash != -1U && !next_hashed) {
|
2021-11-11 17:32:53 -07:00
|
|
|
/* serialize hash clear with wake_up() */
|
|
|
|
|
spin_lock_irq(&wq->hash->wait.lock);
|
2021-02-19 12:33:30 -07:00
|
|
|
clear_bit(hash, &wq->hash->map);
|
2021-08-31 13:57:32 -06:00
|
|
|
clear_bit(IO_ACCT_STALLED_BIT, &acct->flags);
|
2021-11-11 17:32:53 -07:00
|
|
|
spin_unlock_irq(&wq->hash->wait.lock);
|
2021-02-19 12:33:30 -07:00
|
|
|
if (wq_has_sleeper(&wq->hash->wait))
|
|
|
|
|
wake_up(&wq->hash->wait);
|
2020-03-04 16:14:09 +03:00
|
|
|
}
|
2020-03-04 16:14:10 +03:00
|
|
|
} while (work);
|
2023-08-09 12:59:40 -06:00
|
|
|
|
|
|
|
|
if (!__io_acct_run_queue(acct))
|
|
|
|
|
break;
|
|
|
|
|
raw_spin_lock(&acct->lock);
|
2019-10-22 10:25:58 -06:00
|
|
|
} while (1);
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static int io_wq_worker(void *data)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
|
|
|
|
struct io_worker *worker = data;
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = io_wq_get_acct(worker);
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = worker->wq;
|
2023-03-08 07:18:51 -07:00
|
|
|
bool exit_mask = false, last_timeout = false;
|
2024-11-29 20:06:55 -08:00
|
|
|
char buf[TASK_COMM_LEN] = {};
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2024-05-07 10:00:01 -07:00
|
|
|
set_mask_bits(&worker->flags, 0,
|
|
|
|
|
BIT(IO_WORKER_F_UP) | BIT(IO_WORKER_F_RUNNING));
|
2021-03-04 12:39:36 -07:00
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
snprintf(buf, sizeof(buf), "iou-wrk-%d", wq->task->pid);
|
2021-03-04 12:39:36 -07:00
|
|
|
set_task_comm(current, buf);
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
while (!test_bit(IO_WQ_BIT_EXIT, &wq->state)) {
|
2021-03-12 20:26:13 -07:00
|
|
|
long ret;
|
|
|
|
|
|
2019-12-07 21:03:59 -07:00
|
|
|
set_current_state(TASK_INTERRUPTIBLE);
|
2023-08-09 12:59:40 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we have work to do, io_acct_run_queue() returns with
|
|
|
|
|
* the acct->lock held. If not, it will drop it.
|
|
|
|
|
*/
|
2022-02-06 17:52:40 +08:00
|
|
|
while (io_acct_run_queue(acct))
|
2023-08-09 12:59:40 -06:00
|
|
|
io_worker_handle_work(acct, worker);
|
2022-02-06 17:52:40 +08:00
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2023-03-08 07:18:51 -07:00
|
|
|
/*
|
|
|
|
|
* Last sleep timed out. Exit if we're not the last worker,
|
2026-02-02 22:37:53 +08:00
|
|
|
* or if someone modified our affinity. If wq is marked
|
|
|
|
|
* idle-exit, drop the worker as well. This is used to avoid
|
|
|
|
|
* keeping io-wq workers around for tasks that no longer have
|
|
|
|
|
* any active io_uring instances.
|
2023-03-08 07:18:51 -07:00
|
|
|
*/
|
2026-02-02 22:37:53 +08:00
|
|
|
if ((last_timeout && (exit_mask || acct->nr_workers > 1)) ||
|
|
|
|
|
test_bit(IO_WQ_BIT_EXIT_ON_IDLE, &wq->state)) {
|
2021-09-12 03:40:52 +08:00
|
|
|
acct->nr_workers--;
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-09-01 13:01:17 -06:00
|
|
|
__set_current_state(TASK_RUNNING);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
last_timeout = false;
|
2025-01-28 14:39:22 +01:00
|
|
|
__io_worker_idle(acct, worker);
|
|
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2022-06-21 10:09:02 +01:00
|
|
|
if (io_run_task_work())
|
2021-03-21 07:06:56 -06:00
|
|
|
continue;
|
2021-03-12 20:26:13 -07:00
|
|
|
ret = schedule_timeout(WORKER_IDLE_TIMEOUT);
|
2021-03-25 18:16:06 -06:00
|
|
|
if (signal_pending(current)) {
|
|
|
|
|
struct ksignal ksig;
|
|
|
|
|
|
|
|
|
|
if (!get_signal(&ksig))
|
|
|
|
|
continue;
|
2021-09-27 10:04:10 -06:00
|
|
|
break;
|
2021-03-25 18:16:06 -06:00
|
|
|
}
|
2023-03-08 07:18:51 -07:00
|
|
|
if (!ret) {
|
|
|
|
|
last_timeout = true;
|
|
|
|
|
exit_mask = !cpumask_test_cpu(raw_smp_processor_id(),
|
2023-03-21 22:16:28 -03:00
|
|
|
wq->cpu_mask);
|
2023-03-08 07:18:51 -07:00
|
|
|
}
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
2023-08-09 12:59:40 -06:00
|
|
|
if (test_bit(IO_WQ_BIT_EXIT, &wq->state) && io_acct_run_queue(acct))
|
|
|
|
|
io_worker_handle_work(acct, worker);
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
io_worker_exit(worker);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Called when a worker is scheduled in. Mark us as currently running.
|
|
|
|
|
*/
|
|
|
|
|
void io_wq_worker_running(struct task_struct *tsk)
|
|
|
|
|
{
|
2021-12-22 22:10:09 -06:00
|
|
|
struct io_worker *worker = tsk->worker_private;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-02-16 14:15:30 -07:00
|
|
|
if (!worker)
|
|
|
|
|
return;
|
2024-05-07 10:00:01 -07:00
|
|
|
if (!test_bit(IO_WORKER_F_UP, &worker->flags))
|
2019-10-22 10:25:58 -06:00
|
|
|
return;
|
2024-05-07 10:00:01 -07:00
|
|
|
if (test_bit(IO_WORKER_F_RUNNING, &worker->flags))
|
2019-10-22 10:25:58 -06:00
|
|
|
return;
|
2024-05-07 10:00:01 -07:00
|
|
|
set_bit(IO_WORKER_F_RUNNING, &worker->flags);
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_inc_running(worker);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Called when worker is going to sleep. If there are no workers currently
|
2021-03-08 09:37:51 -07:00
|
|
|
* running and we have work pending, wake up a free one or create a new one.
|
2019-10-22 10:25:58 -06:00
|
|
|
*/
|
|
|
|
|
void io_wq_worker_sleeping(struct task_struct *tsk)
|
|
|
|
|
{
|
2021-12-22 22:10:09 -06:00
|
|
|
struct io_worker *worker = tsk->worker_private;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-02-16 14:15:30 -07:00
|
|
|
if (!worker)
|
|
|
|
|
return;
|
2024-05-07 10:00:01 -07:00
|
|
|
if (!test_bit(IO_WORKER_F_UP, &worker->flags))
|
2019-10-22 10:25:58 -06:00
|
|
|
return;
|
2024-05-07 10:00:01 -07:00
|
|
|
if (!test_bit(IO_WORKER_F_RUNNING, &worker->flags))
|
2019-10-22 10:25:58 -06:00
|
|
|
return;
|
|
|
|
|
|
2024-05-07 10:00:01 -07:00
|
|
|
clear_bit(IO_WORKER_F_RUNNING, &worker->flags);
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_dec_running(worker);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
static void io_init_new_worker(struct io_wq *wq, struct io_wq_acct *acct, struct io_worker *worker,
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
struct task_struct *tsk)
|
2021-02-16 14:15:30 -07:00
|
|
|
{
|
2021-12-22 22:10:09 -06:00
|
|
|
tsk->worker_private = worker;
|
2021-03-04 12:39:36 -07:00
|
|
|
worker->task = tsk;
|
2023-03-21 22:16:28 -03:00
|
|
|
set_cpus_allowed_ptr(tsk, wq->cpu_mask);
|
2021-03-04 12:39:36 -07:00
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
|
|
|
|
hlist_nulls_add_head_rcu(&worker->nulls_node, &acct->free_list);
|
|
|
|
|
list_add_tail_rcu(&worker->all_list, &acct->all_list);
|
2024-05-07 10:00:01 -07:00
|
|
|
set_bit(IO_WORKER_F_FREE, &worker->flags);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-03-04 12:39:36 -07:00
|
|
|
wake_up_new_task(tsk);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
static bool io_wq_work_match_all(struct io_wq_work *work, void *data)
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-10 18:58:17 +01:00
|
|
|
static inline bool io_should_retry_thread(struct io_worker *worker, long err)
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
{
|
2021-12-02 19:40:15 -07:00
|
|
|
/*
|
|
|
|
|
* Prevent perpetual task_work retry, if the task (or its group) is
|
|
|
|
|
* exiting.
|
|
|
|
|
*/
|
|
|
|
|
if (fatal_signal_pending(current))
|
|
|
|
|
return false;
|
|
|
|
|
|
2025-12-02 13:57:44 -07:00
|
|
|
worker->init_retries++;
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
switch (err) {
|
|
|
|
|
case -EAGAIN:
|
2025-12-02 13:57:44 -07:00
|
|
|
return worker->init_retries <= WORKER_INIT_LIMIT;
|
|
|
|
|
/* Analogous to a fork() syscall, always retry on a restartable error */
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
case -ERESTARTSYS:
|
|
|
|
|
case -ERESTARTNOINTR:
|
|
|
|
|
case -ERESTARTNOHAND:
|
|
|
|
|
return true;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
io-wq: backoff when retrying worker creation
When io_uring submission goes async for the first time on a given task,
we'll try to create a worker thread to handle the submission. Creating
this worker thread can fail due to various transient conditions, such as
an outstanding signal in the forking thread, so we have retry logic with
a limit of 3 retries. However, this retry logic appears to be too
aggressive/fast - we've observed a thread blowing through the retry
limit while having the same outstanding signal the whole time. Here's an
excerpt of some tracing that demonstrates the issue:
First, signal 26 is generated for the process. It ends up getting routed
to thread 92942.
0) cbd-92284 /* signal_generate: sig=26 errno=0 code=-2 comm=psblkdASD pid=92934 grp=1 res=0 */
This causes create_io_thread in the signalled thread to fail with
ERESTARTNOINTR, and thus a retry is queued.
13) task_th-92942 /* io_uring_queue_async_work: ring 000000007325c9ae, request 0000000080c96d8e, user_data 0x0, opcode URING_CMD, flags 0x8240001, normal queue, work 000000006e96dd3f */
13) task_th-92942 io_wq_enqueue() {
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 io_wq_activate_free_worker();
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 create_io_worker() {
13) task_th-92942 __kmalloc_cache_noprof();
13) task_th-92942 __init_swait_queue_head();
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
...
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_io_worker+0x8a/0x1a0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 queue_work_on() {
...
The CPU is then handed to a kworker to process the queued retry:
------------------------------------------
13) task_th-92942 => kworker-54154
------------------------------------------
13) kworker-54154 io_workqueue_create() {
13) kworker-54154 io_queue_worker_create() {
13) kworker-54154 task_work_add() {
13) kworker-54154 wake_up_state() {
13) kworker-54154 try_to_wake_up() {
13) kworker-54154 _raw_spin_lock_irqsave();
13) kworker-54154 _raw_spin_unlock_irqrestore();
13) kworker-54154 } /* try_to_wake_up */
13) kworker-54154 } /* wake_up_state */
13) kworker-54154 kick_process();
13) kworker-54154 } /* task_work_add */
13) kworker-54154 } /* io_queue_worker_create */
13) kworker-54154 } /* io_workqueue_create */
And then we immediately switch back to the original task to try creating
a worker again. This fails, because the original task still hasn't
handled its signal.
-----------------------------------------
13) kworker-54154 => task_th-92942
------------------------------------------
13) task_th-92942 create_worker_cont() {
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
13) task_th-92942 } /* kprobe_ftrace_handler */
13) task_th-92942 create_io_thread() {
13) task_th-92942 copy_process() {
13) task_th-92942 task_active_pid_ns();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 recalc_sigpending();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_worker_cont+0x35/0x1b0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 io_worker_release();
13) task_th-92942 queue_work_on() {
13) task_th-92942 clear_pending_if_disabled();
13) task_th-92942 __queue_work() {
13) task_th-92942 } /* __queue_work */
13) task_th-92942 } /* queue_work_on */
13) task_th-92942 } /* create_worker_cont */
The pattern repeats another couple times until we blow through the retry
counter, at which point we give up. All outstanding work is canceled,
and the io_uring command which triggered all this is failed with
ECANCELED:
13) task_th-92942 io_acct_cancel_pending_work() {
...
13) task_th-92942 /* io_uring_complete: ring 000000007325c9ae, req 0000000080c96d8e, user_data 0x0, result -125, cflags 0x0 extra1 0 extra2 0 */
Finally, the task gets around to processing its outstanding signal 26,
but it's too late.
13) task_th-92942 /* signal_deliver: sig=26 errno=0 code=-2 sa_handler=59566a0 sa_flags=14000000 */
Try to address this issue by adding a small scaling delay when retrying
worker creation. This should give the forking thread time to handle its
signal in the above case. This isn't a particularly satisfying solution,
as sufficiently paradoxical scheduling would still have us hitting the
same issue, and I'm open to suggestions for something better. But this
is likely to prevent this (already rare) issue from hitting in practice.
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Link: https://lore.kernel.org/r/20250208-wq_retry-v2-1-4f6f5041d303@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-08 13:42:13 -07:00
|
|
|
static void queue_create_worker_retry(struct io_worker *worker)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* We only bother retrying because there's a chance that the
|
|
|
|
|
* failure to create a worker is due to some temporary condition
|
|
|
|
|
* in the forking task (e.g. outstanding signal); give the task
|
|
|
|
|
* some time to clear that condition.
|
|
|
|
|
*/
|
|
|
|
|
schedule_delayed_work(&worker->work,
|
|
|
|
|
msecs_to_jiffies(worker->init_retries * 5));
|
|
|
|
|
}
|
|
|
|
|
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
static void create_worker_cont(struct callback_head *cb)
|
|
|
|
|
{
|
|
|
|
|
struct io_worker *worker;
|
|
|
|
|
struct task_struct *tsk;
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq;
|
2025-01-28 14:39:22 +01:00
|
|
|
struct io_wq_acct *acct;
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
|
|
|
|
|
worker = container_of(cb, struct io_worker, create_work);
|
|
|
|
|
clear_bit_unlock(0, &worker->create_state);
|
2023-03-21 22:16:28 -03:00
|
|
|
wq = worker->wq;
|
2025-01-28 14:39:22 +01:00
|
|
|
acct = io_wq_get_acct(worker);
|
2023-03-21 22:16:28 -03:00
|
|
|
tsk = create_io_thread(io_wq_worker, worker, NUMA_NO_NODE);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
if (!IS_ERR(tsk)) {
|
2025-01-28 14:39:22 +01:00
|
|
|
io_init_new_worker(wq, acct, worker, tsk);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
io_worker_release(worker);
|
|
|
|
|
return;
|
2024-07-10 18:58:17 +01:00
|
|
|
} else if (!io_should_retry_thread(worker, PTR_ERR(tsk))) {
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
atomic_dec(&acct->nr_running);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
acct->nr_workers--;
|
|
|
|
|
if (!acct->nr_workers) {
|
|
|
|
|
struct io_cb_cancel_data match = {
|
|
|
|
|
.fn = io_wq_work_match_all,
|
|
|
|
|
.cancel_all = true,
|
|
|
|
|
};
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
while (io_acct_cancel_pending_work(wq, acct, &match))
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
;
|
|
|
|
|
} else {
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
}
|
2023-03-21 22:16:28 -03:00
|
|
|
io_worker_ref_put(wq);
|
2021-09-09 19:58:22 +08:00
|
|
|
kfree(worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* re-create attempts grab a new worker ref, drop the existing one */
|
|
|
|
|
io_worker_release(worker);
|
io-wq: backoff when retrying worker creation
When io_uring submission goes async for the first time on a given task,
we'll try to create a worker thread to handle the submission. Creating
this worker thread can fail due to various transient conditions, such as
an outstanding signal in the forking thread, so we have retry logic with
a limit of 3 retries. However, this retry logic appears to be too
aggressive/fast - we've observed a thread blowing through the retry
limit while having the same outstanding signal the whole time. Here's an
excerpt of some tracing that demonstrates the issue:
First, signal 26 is generated for the process. It ends up getting routed
to thread 92942.
0) cbd-92284 /* signal_generate: sig=26 errno=0 code=-2 comm=psblkdASD pid=92934 grp=1 res=0 */
This causes create_io_thread in the signalled thread to fail with
ERESTARTNOINTR, and thus a retry is queued.
13) task_th-92942 /* io_uring_queue_async_work: ring 000000007325c9ae, request 0000000080c96d8e, user_data 0x0, opcode URING_CMD, flags 0x8240001, normal queue, work 000000006e96dd3f */
13) task_th-92942 io_wq_enqueue() {
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 io_wq_activate_free_worker();
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 create_io_worker() {
13) task_th-92942 __kmalloc_cache_noprof();
13) task_th-92942 __init_swait_queue_head();
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
...
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_io_worker+0x8a/0x1a0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 queue_work_on() {
...
The CPU is then handed to a kworker to process the queued retry:
------------------------------------------
13) task_th-92942 => kworker-54154
------------------------------------------
13) kworker-54154 io_workqueue_create() {
13) kworker-54154 io_queue_worker_create() {
13) kworker-54154 task_work_add() {
13) kworker-54154 wake_up_state() {
13) kworker-54154 try_to_wake_up() {
13) kworker-54154 _raw_spin_lock_irqsave();
13) kworker-54154 _raw_spin_unlock_irqrestore();
13) kworker-54154 } /* try_to_wake_up */
13) kworker-54154 } /* wake_up_state */
13) kworker-54154 kick_process();
13) kworker-54154 } /* task_work_add */
13) kworker-54154 } /* io_queue_worker_create */
13) kworker-54154 } /* io_workqueue_create */
And then we immediately switch back to the original task to try creating
a worker again. This fails, because the original task still hasn't
handled its signal.
-----------------------------------------
13) kworker-54154 => task_th-92942
------------------------------------------
13) task_th-92942 create_worker_cont() {
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
13) task_th-92942 } /* kprobe_ftrace_handler */
13) task_th-92942 create_io_thread() {
13) task_th-92942 copy_process() {
13) task_th-92942 task_active_pid_ns();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 recalc_sigpending();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_worker_cont+0x35/0x1b0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 io_worker_release();
13) task_th-92942 queue_work_on() {
13) task_th-92942 clear_pending_if_disabled();
13) task_th-92942 __queue_work() {
13) task_th-92942 } /* __queue_work */
13) task_th-92942 } /* queue_work_on */
13) task_th-92942 } /* create_worker_cont */
The pattern repeats another couple times until we blow through the retry
counter, at which point we give up. All outstanding work is canceled,
and the io_uring command which triggered all this is failed with
ECANCELED:
13) task_th-92942 io_acct_cancel_pending_work() {
...
13) task_th-92942 /* io_uring_complete: ring 000000007325c9ae, req 0000000080c96d8e, user_data 0x0, result -125, cflags 0x0 extra1 0 extra2 0 */
Finally, the task gets around to processing its outstanding signal 26,
but it's too late.
13) task_th-92942 /* signal_deliver: sig=26 errno=0 code=-2 sa_handler=59566a0 sa_flags=14000000 */
Try to address this issue by adding a small scaling delay when retrying
worker creation. This should give the forking thread time to handle its
signal in the above case. This isn't a particularly satisfying solution,
as sufficiently paradoxical scheduling would still have us hitting the
same issue, and I'm open to suggestions for something better. But this
is likely to prevent this (already rare) issue from hitting in practice.
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Link: https://lore.kernel.org/r/20250208-wq_retry-v2-1-4f6f5041d303@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-08 13:42:13 -07:00
|
|
|
queue_create_worker_retry(worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void io_workqueue_create(struct work_struct *work)
|
|
|
|
|
{
|
io-wq: backoff when retrying worker creation
When io_uring submission goes async for the first time on a given task,
we'll try to create a worker thread to handle the submission. Creating
this worker thread can fail due to various transient conditions, such as
an outstanding signal in the forking thread, so we have retry logic with
a limit of 3 retries. However, this retry logic appears to be too
aggressive/fast - we've observed a thread blowing through the retry
limit while having the same outstanding signal the whole time. Here's an
excerpt of some tracing that demonstrates the issue:
First, signal 26 is generated for the process. It ends up getting routed
to thread 92942.
0) cbd-92284 /* signal_generate: sig=26 errno=0 code=-2 comm=psblkdASD pid=92934 grp=1 res=0 */
This causes create_io_thread in the signalled thread to fail with
ERESTARTNOINTR, and thus a retry is queued.
13) task_th-92942 /* io_uring_queue_async_work: ring 000000007325c9ae, request 0000000080c96d8e, user_data 0x0, opcode URING_CMD, flags 0x8240001, normal queue, work 000000006e96dd3f */
13) task_th-92942 io_wq_enqueue() {
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 io_wq_activate_free_worker();
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 create_io_worker() {
13) task_th-92942 __kmalloc_cache_noprof();
13) task_th-92942 __init_swait_queue_head();
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
...
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_io_worker+0x8a/0x1a0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 queue_work_on() {
...
The CPU is then handed to a kworker to process the queued retry:
------------------------------------------
13) task_th-92942 => kworker-54154
------------------------------------------
13) kworker-54154 io_workqueue_create() {
13) kworker-54154 io_queue_worker_create() {
13) kworker-54154 task_work_add() {
13) kworker-54154 wake_up_state() {
13) kworker-54154 try_to_wake_up() {
13) kworker-54154 _raw_spin_lock_irqsave();
13) kworker-54154 _raw_spin_unlock_irqrestore();
13) kworker-54154 } /* try_to_wake_up */
13) kworker-54154 } /* wake_up_state */
13) kworker-54154 kick_process();
13) kworker-54154 } /* task_work_add */
13) kworker-54154 } /* io_queue_worker_create */
13) kworker-54154 } /* io_workqueue_create */
And then we immediately switch back to the original task to try creating
a worker again. This fails, because the original task still hasn't
handled its signal.
-----------------------------------------
13) kworker-54154 => task_th-92942
------------------------------------------
13) task_th-92942 create_worker_cont() {
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
13) task_th-92942 } /* kprobe_ftrace_handler */
13) task_th-92942 create_io_thread() {
13) task_th-92942 copy_process() {
13) task_th-92942 task_active_pid_ns();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 recalc_sigpending();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_worker_cont+0x35/0x1b0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 io_worker_release();
13) task_th-92942 queue_work_on() {
13) task_th-92942 clear_pending_if_disabled();
13) task_th-92942 __queue_work() {
13) task_th-92942 } /* __queue_work */
13) task_th-92942 } /* queue_work_on */
13) task_th-92942 } /* create_worker_cont */
The pattern repeats another couple times until we blow through the retry
counter, at which point we give up. All outstanding work is canceled,
and the io_uring command which triggered all this is failed with
ECANCELED:
13) task_th-92942 io_acct_cancel_pending_work() {
...
13) task_th-92942 /* io_uring_complete: ring 000000007325c9ae, req 0000000080c96d8e, user_data 0x0, result -125, cflags 0x0 extra1 0 extra2 0 */
Finally, the task gets around to processing its outstanding signal 26,
but it's too late.
13) task_th-92942 /* signal_deliver: sig=26 errno=0 code=-2 sa_handler=59566a0 sa_flags=14000000 */
Try to address this issue by adding a small scaling delay when retrying
worker creation. This should give the forking thread time to handle its
signal in the above case. This isn't a particularly satisfying solution,
as sufficiently paradoxical scheduling would still have us hitting the
same issue, and I'm open to suggestions for something better. But this
is likely to prevent this (already rare) issue from hitting in practice.
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Link: https://lore.kernel.org/r/20250208-wq_retry-v2-1-4f6f5041d303@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-08 13:42:13 -07:00
|
|
|
struct io_worker *worker = container_of(work, struct io_worker,
|
|
|
|
|
work.work);
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = io_wq_get_acct(worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
|
2021-09-11 16:58:47 +08:00
|
|
|
if (!io_queue_worker_create(worker, acct, create_worker_cont))
|
2021-09-09 19:58:22 +08:00
|
|
|
kfree(worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
}
|
|
|
|
|
|
2025-01-28 14:39:21 +01:00
|
|
|
static bool create_io_worker(struct io_wq *wq, struct io_wq_acct *acct)
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
{
|
|
|
|
|
struct io_worker *worker;
|
|
|
|
|
struct task_struct *tsk;
|
|
|
|
|
|
|
|
|
|
__set_current_state(TASK_RUNNING);
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
worker = kzalloc_obj(*worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
if (!worker) {
|
|
|
|
|
fail:
|
|
|
|
|
atomic_dec(&acct->nr_running);
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
acct->nr_workers--;
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
io_worker_ref_put(wq);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
refcount_set(&worker->ref, 1);
|
2023-03-21 22:16:28 -03:00
|
|
|
worker->wq = wq;
|
2025-01-28 14:39:21 +01:00
|
|
|
worker->acct = acct;
|
2022-01-18 19:13:43 -07:00
|
|
|
raw_spin_lock_init(&worker->lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
init_completion(&worker->ref_done);
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
tsk = create_io_thread(io_wq_worker, worker, NUMA_NO_NODE);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
if (!IS_ERR(tsk)) {
|
2025-01-28 14:39:22 +01:00
|
|
|
io_init_new_worker(wq, acct, worker, tsk);
|
2024-07-10 18:58:17 +01:00
|
|
|
} else if (!io_should_retry_thread(worker, PTR_ERR(tsk))) {
|
2021-09-09 19:58:22 +08:00
|
|
|
kfree(worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
goto fail;
|
|
|
|
|
} else {
|
io-wq: backoff when retrying worker creation
When io_uring submission goes async for the first time on a given task,
we'll try to create a worker thread to handle the submission. Creating
this worker thread can fail due to various transient conditions, such as
an outstanding signal in the forking thread, so we have retry logic with
a limit of 3 retries. However, this retry logic appears to be too
aggressive/fast - we've observed a thread blowing through the retry
limit while having the same outstanding signal the whole time. Here's an
excerpt of some tracing that demonstrates the issue:
First, signal 26 is generated for the process. It ends up getting routed
to thread 92942.
0) cbd-92284 /* signal_generate: sig=26 errno=0 code=-2 comm=psblkdASD pid=92934 grp=1 res=0 */
This causes create_io_thread in the signalled thread to fail with
ERESTARTNOINTR, and thus a retry is queued.
13) task_th-92942 /* io_uring_queue_async_work: ring 000000007325c9ae, request 0000000080c96d8e, user_data 0x0, opcode URING_CMD, flags 0x8240001, normal queue, work 000000006e96dd3f */
13) task_th-92942 io_wq_enqueue() {
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 io_wq_activate_free_worker();
13) task_th-92942 _raw_spin_lock();
13) task_th-92942 create_io_worker() {
13) task_th-92942 __kmalloc_cache_noprof();
13) task_th-92942 __init_swait_queue_head();
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
...
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_io_worker+0x8a/0x1a0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 queue_work_on() {
...
The CPU is then handed to a kworker to process the queued retry:
------------------------------------------
13) task_th-92942 => kworker-54154
------------------------------------------
13) kworker-54154 io_workqueue_create() {
13) kworker-54154 io_queue_worker_create() {
13) kworker-54154 task_work_add() {
13) kworker-54154 wake_up_state() {
13) kworker-54154 try_to_wake_up() {
13) kworker-54154 _raw_spin_lock_irqsave();
13) kworker-54154 _raw_spin_unlock_irqrestore();
13) kworker-54154 } /* try_to_wake_up */
13) kworker-54154 } /* wake_up_state */
13) kworker-54154 kick_process();
13) kworker-54154 } /* task_work_add */
13) kworker-54154 } /* io_queue_worker_create */
13) kworker-54154 } /* io_workqueue_create */
And then we immediately switch back to the original task to try creating
a worker again. This fails, because the original task still hasn't
handled its signal.
-----------------------------------------
13) kworker-54154 => task_th-92942
------------------------------------------
13) task_th-92942 create_worker_cont() {
13) task_th-92942 kprobe_ftrace_handler() {
13) task_th-92942 get_kprobe();
13) task_th-92942 aggr_pre_handler() {
13) task_th-92942 pre_handler_kretprobe();
13) task_th-92942 /* create_enter: (create_io_thread+0x0/0x50) fn=0xffffffff8172c0e0 arg=0xffff888996bb69c0 node=-1 */
13) task_th-92942 } /* aggr_pre_handler */
13) task_th-92942 } /* kprobe_ftrace_handler */
13) task_th-92942 create_io_thread() {
13) task_th-92942 copy_process() {
13) task_th-92942 task_active_pid_ns();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 recalc_sigpending();
13) task_th-92942 _raw_spin_lock_irq();
13) task_th-92942 } /* copy_process */
13) task_th-92942 } /* create_io_thread */
13) task_th-92942 kretprobe_rethook_handler() {
13) task_th-92942 /* create_exit: (create_worker_cont+0x35/0x1b0 <- create_io_thread) arg1=0xfffffffffffffdff */
13) task_th-92942 } /* kretprobe_rethook_handler */
13) task_th-92942 io_worker_release();
13) task_th-92942 queue_work_on() {
13) task_th-92942 clear_pending_if_disabled();
13) task_th-92942 __queue_work() {
13) task_th-92942 } /* __queue_work */
13) task_th-92942 } /* queue_work_on */
13) task_th-92942 } /* create_worker_cont */
The pattern repeats another couple times until we blow through the retry
counter, at which point we give up. All outstanding work is canceled,
and the io_uring command which triggered all this is failed with
ECANCELED:
13) task_th-92942 io_acct_cancel_pending_work() {
...
13) task_th-92942 /* io_uring_complete: ring 000000007325c9ae, req 0000000080c96d8e, user_data 0x0, result -125, cflags 0x0 extra1 0 extra2 0 */
Finally, the task gets around to processing its outstanding signal 26,
but it's too late.
13) task_th-92942 /* signal_deliver: sig=26 errno=0 code=-2 sa_handler=59566a0 sa_flags=14000000 */
Try to address this issue by adding a small scaling delay when retrying
worker creation. This should give the forking thread time to handle its
signal in the above case. This isn't a particularly satisfying solution,
as sufficiently paradoxical scheduling would still have us hitting the
same issue, and I'm open to suggestions for something better. But this
is likely to prevent this (already rare) issue from hitting in practice.
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Link: https://lore.kernel.org/r/20250208-wq_retry-v2-1-4f6f5041d303@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-08 13:42:13 -07:00
|
|
|
INIT_DELAYED_WORK(&worker->work, io_workqueue_create);
|
|
|
|
|
queue_create_worker_retry(worker);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-26 21:26:55 +08:00
|
|
|
/*
|
|
|
|
|
* Iterate the passed in list and call the specific function for each
|
|
|
|
|
* worker that isn't exiting
|
|
|
|
|
*/
|
2025-01-28 14:39:22 +01:00
|
|
|
static bool io_acct_for_each_worker(struct io_wq_acct *acct,
|
|
|
|
|
bool (*func)(struct io_worker *, void *),
|
|
|
|
|
void *data)
|
2020-09-26 21:26:55 +08:00
|
|
|
{
|
|
|
|
|
struct io_worker *worker;
|
|
|
|
|
bool ret = false;
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
list_for_each_entry_rcu(worker, &acct->all_list, all_list) {
|
2020-09-26 21:26:55 +08:00
|
|
|
if (io_worker_get(worker)) {
|
|
|
|
|
/* no task if node is/was offline */
|
|
|
|
|
if (worker->task)
|
|
|
|
|
ret = func(worker, data);
|
|
|
|
|
io_worker_release(worker);
|
|
|
|
|
if (ret)
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2026-01-05 11:42:05 -07:00
|
|
|
static void io_wq_for_each_worker(struct io_wq *wq,
|
2025-01-28 14:39:22 +01:00
|
|
|
bool (*func)(struct io_worker *, void *),
|
|
|
|
|
void *data)
|
|
|
|
|
{
|
2026-01-05 11:42:05 -07:00
|
|
|
for (int i = 0; i < IO_WQ_ACCT_NR; i++)
|
2026-01-05 07:42:48 -07:00
|
|
|
if (io_acct_for_each_worker(&wq->acct[i], func, data))
|
2026-01-05 11:42:05 -07:00
|
|
|
break;
|
2025-01-28 14:39:22 +01:00
|
|
|
}
|
|
|
|
|
|
2020-09-26 21:26:55 +08:00
|
|
|
static bool io_wq_worker_wake(struct io_worker *worker, void *data)
|
|
|
|
|
{
|
2022-04-25 19:49:01 -06:00
|
|
|
__set_notify_signal(worker->task);
|
2020-09-26 21:26:55 +08:00
|
|
|
wake_up_process(worker->task);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2026-02-02 22:37:53 +08:00
|
|
|
void io_wq_set_exit_on_idle(struct io_wq *wq, bool enable)
|
|
|
|
|
{
|
|
|
|
|
if (!wq->task)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!enable) {
|
|
|
|
|
clear_bit(IO_WQ_BIT_EXIT_ON_IDLE, &wq->state);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (test_and_set_bit(IO_WQ_BIT_EXIT_ON_IDLE, &wq->state))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
|
io_wq_for_each_worker(wq, io_wq_worker_wake, NULL);
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static void io_run_cancel(struct io_wq_work *work, struct io_wq *wq)
|
2020-03-01 19:18:19 +03:00
|
|
|
{
|
|
|
|
|
do {
|
2024-06-13 19:28:27 +00:00
|
|
|
atomic_or(IO_WQ_WORK_CANCEL, &work->flags);
|
2025-03-29 10:15:24 -06:00
|
|
|
io_wq_submit_work(work);
|
|
|
|
|
work = io_wq_free_work(work);
|
2020-03-01 19:18:19 +03:00
|
|
|
} while (work);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-28 14:39:23 +01:00
|
|
|
static void io_wq_insert_work(struct io_wq *wq, struct io_wq_acct *acct,
|
|
|
|
|
struct io_wq_work *work, unsigned int work_flags)
|
2020-03-23 22:57:22 +03:00
|
|
|
{
|
|
|
|
|
unsigned int hash;
|
|
|
|
|
struct io_wq_work *tail;
|
|
|
|
|
|
2025-01-28 14:39:23 +01:00
|
|
|
if (!__io_wq_is_hashed(work_flags)) {
|
2020-03-23 22:57:22 +03:00
|
|
|
append:
|
2021-08-31 13:57:32 -06:00
|
|
|
wq_list_add_tail(&work->list, &acct->work_list);
|
2020-03-23 22:57:22 +03:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-28 14:39:23 +01:00
|
|
|
hash = __io_get_work_hash(work_flags);
|
2023-03-21 22:16:28 -03:00
|
|
|
tail = wq->hash_tail[hash];
|
|
|
|
|
wq->hash_tail[hash] = work;
|
2020-03-23 22:57:22 +03:00
|
|
|
if (!tail)
|
|
|
|
|
goto append;
|
|
|
|
|
|
2021-08-31 13:57:32 -06:00
|
|
|
wq_list_add_after(&work->list, &tail->list, &acct->work_list);
|
2020-03-23 22:57:22 +03:00
|
|
|
}
|
|
|
|
|
|
2021-09-08 10:09:29 +01:00
|
|
|
static bool io_wq_work_match_item(struct io_wq_work *work, void *data)
|
|
|
|
|
{
|
|
|
|
|
return work == data;
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
void io_wq_enqueue(struct io_wq *wq, struct io_wq_work *work)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2024-06-13 19:28:27 +00:00
|
|
|
unsigned int work_flags = atomic_read(&work->flags);
|
2025-01-28 14:39:23 +01:00
|
|
|
struct io_wq_acct *acct = io_work_get_acct(wq, work_flags);
|
2024-06-04 20:12:43 +08:00
|
|
|
struct io_cb_cancel_data match = {
|
|
|
|
|
.fn = io_wq_work_match_item,
|
|
|
|
|
.data = work,
|
|
|
|
|
.cancel_all = false,
|
|
|
|
|
};
|
2021-08-30 11:55:22 -06:00
|
|
|
bool do_create;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2021-07-23 11:53:54 -06:00
|
|
|
/*
|
|
|
|
|
* If io-wq is exiting for this task, or if the request has explicitly
|
|
|
|
|
* been marked as one that should not get executed, cancel it here.
|
|
|
|
|
*/
|
2023-03-21 22:16:28 -03:00
|
|
|
if (test_bit(IO_WQ_BIT_EXIT, &wq->state) ||
|
2024-06-13 19:28:27 +00:00
|
|
|
(work_flags & IO_WQ_WORK_CANCEL)) {
|
2023-03-21 22:16:28 -03:00
|
|
|
io_run_cancel(work, wq);
|
2021-02-25 10:17:09 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_lock(&acct->lock);
|
2025-01-28 14:39:23 +01:00
|
|
|
io_wq_insert_work(wq, acct, work, work_flags);
|
2021-08-31 13:57:32 -06:00
|
|
|
clear_bit(IO_ACCT_STALLED_BIT, &acct->flags);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_unlock(&acct->lock);
|
2021-08-30 11:55:22 -06:00
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2025-01-28 14:39:22 +01:00
|
|
|
do_create = !io_acct_activate_free_worker(acct);
|
2021-08-30 11:55:22 -06:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
|
|
if (do_create && ((work_flags & IO_WQ_WORK_CONCURRENT) ||
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
!atomic_read(&acct->nr_running))) {
|
|
|
|
|
bool did_create;
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
did_create = io_wq_create_worker(wq, acct);
|
2021-09-08 10:09:29 +01:00
|
|
|
if (likely(did_create))
|
|
|
|
|
return;
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
if (acct->nr_workers) {
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
return;
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
}
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
|
|
|
|
|
/* fatal condition, failed to create the first worker */
|
2023-03-21 22:16:28 -03:00
|
|
|
io_acct_cancel_pending_work(wq, acct, &match);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
}
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2020-03-14 00:31:04 +03:00
|
|
|
* Work items that hash to the same value will not be done in parallel.
|
|
|
|
|
* Used to limit concurrent writes, generally hashed by inode.
|
2019-10-22 10:25:58 -06:00
|
|
|
*/
|
2020-03-14 00:31:04 +03:00
|
|
|
void io_wq_hash_work(struct io_wq_work *work, void *val)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2020-03-14 00:31:04 +03:00
|
|
|
unsigned int bit;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
|
|
|
|
bit = hash_ptr(val, IO_WQ_HASH_ORDER);
|
2024-06-13 19:28:27 +00:00
|
|
|
atomic_or(IO_WQ_WORK_HASHED | (bit << IO_WQ_HASH_SHIFT), &work->flags);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
2022-01-18 19:23:51 -07:00
|
|
|
static bool __io_wq_worker_cancel(struct io_worker *worker,
|
|
|
|
|
struct io_cb_cancel_data *match,
|
|
|
|
|
struct io_wq_work *work)
|
|
|
|
|
{
|
|
|
|
|
if (work && match->fn(work, match->data)) {
|
2024-06-13 19:28:27 +00:00
|
|
|
atomic_or(IO_WQ_WORK_CANCEL, &work->flags);
|
2022-04-25 19:49:01 -06:00
|
|
|
__set_notify_signal(worker->task);
|
2022-01-18 19:23:51 -07:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-07 01:15:39 +03:00
|
|
|
static bool io_wq_worker_cancel(struct io_worker *worker, void *data)
|
2019-10-28 21:49:21 -06:00
|
|
|
{
|
2020-03-07 01:15:39 +03:00
|
|
|
struct io_cb_cancel_data *match = data;
|
2019-10-28 21:49:21 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Hold the lock to avoid ->cur_work going out of scope, caller
|
2019-11-13 09:43:34 -07:00
|
|
|
* may dereference the passed in work.
|
2019-10-28 21:49:21 -06:00
|
|
|
*/
|
2022-01-18 19:13:43 -07:00
|
|
|
raw_spin_lock(&worker->lock);
|
2024-04-15 22:10:54 -04:00
|
|
|
if (__io_wq_worker_cancel(worker, match, worker->cur_work))
|
2020-06-15 10:24:03 +03:00
|
|
|
match->nr_running++;
|
2022-01-18 19:13:43 -07:00
|
|
|
raw_spin_unlock(&worker->lock);
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2020-06-15 10:24:03 +03:00
|
|
|
return match->nr_running && !match->cancel_all;
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static inline void io_wq_remove_pending(struct io_wq *wq,
|
2025-01-28 14:39:20 +01:00
|
|
|
struct io_wq_acct *acct,
|
2020-08-23 20:33:10 +03:00
|
|
|
struct io_wq_work *work,
|
|
|
|
|
struct io_wq_work_node *prev)
|
|
|
|
|
{
|
|
|
|
|
unsigned int hash = io_get_work_hash(work);
|
|
|
|
|
struct io_wq_work *prev_work = NULL;
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
if (io_wq_is_hashed(work) && work == wq->hash_tail[hash]) {
|
2020-08-23 20:33:10 +03:00
|
|
|
if (prev)
|
|
|
|
|
prev_work = container_of(prev, struct io_wq_work, list);
|
io-wq: check that the predecessor is hashed in io_wq_remove_pending()
io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled
work was the tail of its hash bucket. When doing this, it checks whether
the preceding entry in acct->work_list has the same hash value, but
never checks that the predecessor is hashed at all. io_get_work_hash()
is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash
bits are never set for non-hashed work, so it returns 0. Thus, when a
hashed bucket-0 work is cancelled while a non-hashed work is its list
predecessor, the check spuriously passes and a pointer to the non-hashed
io_kiocb is stored in wq->hash_tail[0].
Because non-hashed work is dequeued via the fast path in
io_get_next_work(), which never touches hash_tail[], the stale pointer
is never cleared. Therefore, after the non-hashed io_kiocb completes and
is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The
io_wq is per-task (tctx->io_wq) and survives ring open/close, so the
dangling pointer persists for the lifetime of the task; the next hashed
bucket-0 enqueue dereferences it in io_wq_insert_work() and
wq_list_add_after() writes through freed memory.
Add the missing io_wq_is_hashed() check so a non-hashed predecessor
never inherits a hash_tail[] slot.
Cc: stable@vger.kernel.org
Fixes: 204361a77f40 ("io-wq: fix hang after cancelling pending hashed work")
Signed-off-by: Nicholas Carlini <nicholas@carlini.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-11 18:02:16 +00:00
|
|
|
if (prev_work && io_wq_is_hashed(prev_work) &&
|
|
|
|
|
io_get_work_hash(prev_work) == hash)
|
2023-03-21 22:16:28 -03:00
|
|
|
wq->hash_tail[hash] = prev_work;
|
2020-08-23 20:33:10 +03:00
|
|
|
else
|
2023-03-21 22:16:28 -03:00
|
|
|
wq->hash_tail[hash] = NULL;
|
2020-08-23 20:33:10 +03:00
|
|
|
}
|
2021-08-31 13:57:32 -06:00
|
|
|
wq_list_del(&acct->work_list, &work->list, prev);
|
2020-08-23 20:33:10 +03:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static bool io_acct_cancel_pending_work(struct io_wq *wq,
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct,
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
struct io_cb_cancel_data *match)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2019-11-26 11:59:32 -07:00
|
|
|
struct io_wq_work_node *node, *prev;
|
2019-10-22 10:25:58 -06:00
|
|
|
struct io_wq_work *work;
|
|
|
|
|
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_lock(&acct->lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
wq_list_for_each(node, prev, &acct->work_list) {
|
|
|
|
|
work = container_of(node, struct io_wq_work, list);
|
|
|
|
|
if (!match->fn(work, match->data))
|
|
|
|
|
continue;
|
2025-01-28 14:39:20 +01:00
|
|
|
io_wq_remove_pending(wq, acct, work, prev);
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_unlock(&acct->lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
io_run_cancel(work, wq);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
match->nr_pending++;
|
|
|
|
|
/* not safe to continue after unlock */
|
|
|
|
|
return true;
|
|
|
|
|
}
|
io-wq: decouple work_list protection from the big wqe->lock
wqe->lock is abused, it now protects acct->work_list, hash stuff,
nr_workers, wqe->free_list and so on. Lets first get the work_list out
of the wqe-lock mess by introduce a specific lock for work list. This
is the first step to solve the huge contension between work insertion
and work consumption.
good thing:
- split locking for bound and unbound work list
- reduce contension between work_list visit and (worker's)free_list.
For the hash stuff, since there won't be a work with same file in both
bound and unbound work list, thus they won't visit same hash entry. it
works well to use the new lock to protect hash stuff.
Results:
set max_unbound_worker = 4, test with echo-server:
nice -n -15 ./io_uring_echo_server -p 8081 -f -n 1000 -l 16
(-n connection, -l workload)
before this patch:
Samples: 2M of event 'cycles:ppp', Event count (approx.): 1239982111074
Overhead Command Shared Object Symbol
28.59% iou-wrk-10021 [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
8.89% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
6.20% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock
2.45% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
2.36% iou-wrk-10021 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.29% iou-wrk-10021 [kernel.vmlinux] [k] io_worker_handle_work
1.29% io_uring_echo_s [kernel.vmlinux] [k] io_wqe_enqueue
1.06% iou-wrk-10021 [kernel.vmlinux] [k] io_wqe_worker
1.06% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.03% iou-wrk-10021 [kernel.vmlinux] [k] __schedule
0.99% iou-wrk-10021 [kernel.vmlinux] [k] tcp_sendmsg_locked
with this patch:
Samples: 1M of event 'cycles:ppp', Event count (approx.): 708446691943
Overhead Command Shared Object Symbol
16.86% iou-wrk-10893 [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
9.10% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock
4.53% io_uring_echo_s [kernel.vmlinux] [k] native_queued_spin_lock_slowpat
2.87% iou-wrk-10893 [kernel.vmlinux] [k] io_worker_handle_work
2.57% iou-wrk-10893 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
2.56% io_uring_echo_s [kernel.vmlinux] [k] io_prep_async_work
1.82% io_uring_echo_s [kernel.vmlinux] [k] _raw_spin_lock
1.33% iou-wrk-10893 [kernel.vmlinux] [k] io_wqe_worker
1.26% io_uring_echo_s [kernel.vmlinux] [k] try_to_wake_up
spin_lock failure from 25.59% + 8.89% = 34.48% to 16.86% + 4.53% = 21.39%
TPS is similar, while cpu usage is from almost 400% to 350%
Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220206095241.121485-2-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-02-06 17:52:39 +08:00
|
|
|
raw_spin_unlock(&acct->lock);
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static void io_wq_cancel_pending_work(struct io_wq *wq,
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_cb_cancel_data *match)
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
{
|
|
|
|
|
int i;
|
2020-06-15 10:24:03 +03:00
|
|
|
retry:
|
2021-08-31 13:57:32 -06:00
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++) {
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq_acct *acct = io_get_acct(wq, i == 0);
|
2020-06-15 10:24:03 +03:00
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
if (io_acct_cancel_pending_work(wq, acct, match)) {
|
io-wq: make worker creation resilient against signals
If a task is queueing async work and also handling signals, then we can
run into the case where create_io_thread() is interrupted and returns
failure because of that. If this happens for creating the first worker
in a group, then that worker will never get created and we can hang the
ring.
If we do get a fork failure, retry from task_work. With signals we have
to be a bit careful as we cannot simply queue as task_work, as we'll
still have signals pending at that point. Punt over a normal workqueue
first and then create from task_work after that.
Lastly, ensure that we handle fatal worker creations. Worker creation
failures are normally not fatal, only if we fail to create one in an empty
worker group can we not make progress. Right now that is ignored, ensure
that we handle that and run cancel on the work item.
There are two paths that create new workers - one is the "existing worker
going to sleep", and the other is "no workers found for this work, create
one". The former is never fatal, as workers do exist in the group. Only
the latter needs to be carefully handled.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-09-01 11:20:10 -06:00
|
|
|
if (match->cancel_all)
|
|
|
|
|
goto retry;
|
2022-01-18 19:18:20 -07:00
|
|
|
break;
|
2021-08-31 13:57:32 -06:00
|
|
|
}
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
2020-06-15 10:24:02 +03:00
|
|
|
}
|
|
|
|
|
|
2025-01-28 14:39:22 +01:00
|
|
|
static void io_acct_cancel_running_work(struct io_wq_acct *acct,
|
|
|
|
|
struct io_cb_cancel_data *match)
|
|
|
|
|
{
|
|
|
|
|
raw_spin_lock(&acct->workers_lock);
|
|
|
|
|
io_acct_for_each_worker(acct, io_wq_worker_cancel, match);
|
|
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static void io_wq_cancel_running_work(struct io_wq *wq,
|
2020-06-15 10:24:02 +03:00
|
|
|
struct io_cb_cancel_data *match)
|
|
|
|
|
{
|
2019-10-22 10:25:58 -06:00
|
|
|
rcu_read_lock();
|
2025-01-28 14:39:22 +01:00
|
|
|
|
|
|
|
|
for (int i = 0; i < IO_WQ_ACCT_NR; i++)
|
|
|
|
|
io_acct_cancel_running_work(&wq->acct[i], match);
|
|
|
|
|
|
2019-10-22 10:25:58 -06:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-07 01:15:39 +03:00
|
|
|
enum io_wq_cancel io_wq_cancel_cb(struct io_wq *wq, work_cancel_fn *cancel,
|
2020-06-15 10:24:03 +03:00
|
|
|
void *data, bool cancel_all)
|
2020-03-07 01:15:39 +03:00
|
|
|
{
|
|
|
|
|
struct io_cb_cancel_data match = {
|
2020-06-15 10:24:03 +03:00
|
|
|
.fn = cancel,
|
|
|
|
|
.data = data,
|
|
|
|
|
.cancel_all = cancel_all,
|
2020-03-07 01:15:39 +03:00
|
|
|
};
|
|
|
|
|
|
2020-06-15 10:24:02 +03:00
|
|
|
/*
|
|
|
|
|
* First check pending list, if we're lucky we can just remove it
|
|
|
|
|
* from there. CANCEL_OK means that the work is returned as-new,
|
|
|
|
|
* no completion will be posted for it.
|
2022-01-18 19:22:32 -07:00
|
|
|
*
|
|
|
|
|
* Then check if a free (going busy) or busy worker has the work
|
2020-06-15 10:24:02 +03:00
|
|
|
* currently running. If we find it there, we'll return CANCEL_RUNNING
|
|
|
|
|
* as an indication that we attempt to signal cancellation. The
|
|
|
|
|
* completion will run normally in this case.
|
2022-01-18 19:22:32 -07:00
|
|
|
*
|
2025-01-28 14:39:22 +01:00
|
|
|
* Do both of these while holding the acct->workers_lock, to ensure that
|
2022-01-18 19:22:32 -07:00
|
|
|
* we'll find a work item regardless of state.
|
2020-06-15 10:24:02 +03:00
|
|
|
*/
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_cancel_pending_work(wq, &match);
|
2023-03-10 12:11:07 -08:00
|
|
|
if (match.nr_pending && !match.cancel_all)
|
|
|
|
|
return IO_WQ_CANCEL_OK;
|
2020-06-15 10:24:02 +03:00
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_cancel_running_work(wq, &match);
|
2023-03-10 12:11:07 -08:00
|
|
|
if (match.nr_running && !match.cancel_all)
|
|
|
|
|
return IO_WQ_CANCEL_RUNNING;
|
2020-06-15 10:24:02 +03:00
|
|
|
|
2020-06-15 10:24:03 +03:00
|
|
|
if (match.nr_running)
|
|
|
|
|
return IO_WQ_CANCEL_RUNNING;
|
|
|
|
|
if (match.nr_pending)
|
|
|
|
|
return IO_WQ_CANCEL_OK;
|
2020-06-15 10:24:02 +03:00
|
|
|
return IO_WQ_CANCEL_NOTFOUND;
|
2020-03-07 01:15:39 +03:00
|
|
|
}
|
|
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
static int io_wq_hash_wake(struct wait_queue_entry *wait, unsigned mode,
|
2021-02-19 12:33:30 -07:00
|
|
|
int sync, void *key)
|
|
|
|
|
{
|
2023-03-21 22:16:28 -03:00
|
|
|
struct io_wq *wq = container_of(wait, struct io_wq, wait);
|
2021-08-31 13:57:32 -06:00
|
|
|
int i;
|
2021-02-19 12:33:30 -07:00
|
|
|
|
|
|
|
|
list_del_init(&wait->entry);
|
|
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2021-08-31 13:57:32 -06:00
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++) {
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = &wq->acct[i];
|
2021-08-31 13:57:32 -06:00
|
|
|
|
|
|
|
|
if (test_and_clear_bit(IO_ACCT_STALLED_BIT, &acct->flags))
|
2025-01-28 14:39:22 +01:00
|
|
|
io_acct_activate_free_worker(acct);
|
2021-08-31 13:57:32 -06:00
|
|
|
}
|
2021-02-19 12:33:30 -07:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-25 08:49:20 -07:00
|
|
|
struct io_wq *io_wq_create(unsigned bounded, struct io_wq_data *data)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2023-03-10 12:11:07 -08:00
|
|
|
int ret, i;
|
2019-10-22 10:25:58 -06:00
|
|
|
struct io_wq *wq;
|
|
|
|
|
|
2021-06-17 18:13:59 +01:00
|
|
|
if (WARN_ON_ONCE(!bounded))
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
2020-03-04 16:14:12 +03:00
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
wq = kzalloc_obj(struct io_wq);
|
2019-10-22 10:25:58 -06:00
|
|
|
if (!wq)
|
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
2021-02-19 12:33:30 -07:00
|
|
|
refcount_inc(&data->hash->refs);
|
|
|
|
|
wq->hash = data->hash;
|
2019-11-12 22:31:31 -07:00
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
ret = -ENOMEM;
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2023-03-21 22:16:28 -03:00
|
|
|
if (!alloc_cpumask_var(&wq->cpu_mask, GFP_KERNEL))
|
2023-03-10 12:11:07 -08:00
|
|
|
goto err;
|
2024-09-10 19:11:57 +02:00
|
|
|
cpuset_cpus_allowed(data->task, wq->cpu_mask);
|
2023-03-21 22:16:27 -03:00
|
|
|
wq->acct[IO_WQ_ACCT_BOUND].max_workers = bounded;
|
|
|
|
|
wq->acct[IO_WQ_ACCT_UNBOUND].max_workers =
|
2023-03-10 12:11:07 -08:00
|
|
|
task_rlimit(current, RLIMIT_NPROC);
|
2023-03-21 22:16:28 -03:00
|
|
|
INIT_LIST_HEAD(&wq->wait.entry);
|
|
|
|
|
wq->wait.func = io_wq_hash_wake;
|
2023-03-10 12:11:07 -08:00
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++) {
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct = &wq->acct[i];
|
2021-08-31 13:57:32 -06:00
|
|
|
|
2023-03-10 12:11:07 -08:00
|
|
|
atomic_set(&acct->nr_running, 0);
|
2025-01-28 14:39:22 +01:00
|
|
|
|
|
|
|
|
raw_spin_lock_init(&acct->workers_lock);
|
|
|
|
|
INIT_HLIST_NULLS_HEAD(&acct->free_list, 0);
|
|
|
|
|
INIT_LIST_HEAD(&acct->all_list);
|
|
|
|
|
|
2023-03-10 12:11:07 -08:00
|
|
|
INIT_WQ_LIST(&acct->work_list);
|
|
|
|
|
raw_spin_lock_init(&acct->lock);
|
2019-10-22 10:25:58 -06:00
|
|
|
}
|
2023-03-21 22:16:28 -03:00
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
wq->task = get_task_struct(data->task);
|
|
|
|
|
atomic_set(&wq->worker_refs, 1);
|
|
|
|
|
init_completion(&wq->worker_done);
|
2023-10-05 13:55:31 -04:00
|
|
|
ret = cpuhp_state_add_instance_nocalls(io_wq_online, &wq->cpuhp_node);
|
2025-06-15 09:39:06 -07:00
|
|
|
if (ret) {
|
|
|
|
|
put_task_struct(wq->task);
|
2023-10-05 13:55:31 -04:00
|
|
|
goto err;
|
2025-06-15 09:39:06 -07:00
|
|
|
}
|
2023-10-05 13:55:31 -04:00
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
return wq;
|
2019-11-19 08:37:07 -07:00
|
|
|
err:
|
2021-03-01 09:09:56 -07:00
|
|
|
io_wq_put_hash(data->hash);
|
2023-03-21 22:16:28 -03:00
|
|
|
free_cpumask_var(wq->cpu_mask);
|
2019-11-19 08:37:07 -07:00
|
|
|
kfree(wq);
|
2019-10-22 10:25:58 -06:00
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-01 19:57:07 -06:00
|
|
|
static bool io_task_work_match(struct callback_head *cb, void *data)
|
|
|
|
|
{
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
struct io_worker *worker;
|
2021-04-01 19:57:07 -06:00
|
|
|
|
2021-09-08 19:57:26 -06:00
|
|
|
if (cb->func != create_worker_cb && cb->func != create_worker_cont)
|
2021-04-01 19:57:07 -06:00
|
|
|
return false;
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
worker = container_of(cb, struct io_worker, create_work);
|
2023-03-21 22:16:28 -03:00
|
|
|
return worker->wq == data;
|
2021-04-01 19:57:07 -06:00
|
|
|
}
|
|
|
|
|
|
2021-05-23 15:48:39 +01:00
|
|
|
void io_wq_exit_start(struct io_wq *wq)
|
|
|
|
|
{
|
|
|
|
|
set_bit(IO_WQ_BIT_EXIT, &wq->state);
|
|
|
|
|
}
|
|
|
|
|
|
2021-12-10 08:29:30 -07:00
|
|
|
static void io_wq_cancel_tw_create(struct io_wq *wq)
|
2021-02-26 13:48:19 -07:00
|
|
|
{
|
2021-03-08 09:37:51 -07:00
|
|
|
struct callback_head *cb;
|
|
|
|
|
|
2021-04-01 19:57:07 -06:00
|
|
|
while ((cb = task_work_cancel_match(wq->task, io_task_work_match, wq)) != NULL) {
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
struct io_worker *worker;
|
2021-03-08 09:37:51 -07:00
|
|
|
|
io-wq: remove GFP_ATOMIC allocation off schedule out path
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-08-04 08:37:25 -06:00
|
|
|
worker = container_of(cb, struct io_worker, create_work);
|
2021-10-29 13:11:33 +01:00
|
|
|
io_worker_cancel_cb(worker);
|
2023-01-08 10:39:17 -07:00
|
|
|
/*
|
|
|
|
|
* Only the worker continuation helper has worker allocated and
|
|
|
|
|
* hence needs freeing.
|
|
|
|
|
*/
|
|
|
|
|
if (cb->func == create_worker_cont)
|
|
|
|
|
kfree(worker);
|
2021-02-26 13:48:19 -07:00
|
|
|
}
|
2021-12-10 08:29:30 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void io_wq_exit_workers(struct io_wq *wq)
|
|
|
|
|
{
|
2026-01-21 10:40:33 -07:00
|
|
|
unsigned long timeout, warn_timeout;
|
|
|
|
|
|
2021-12-10 08:29:30 -07:00
|
|
|
if (!wq->task)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
io_wq_cancel_tw_create(wq);
|
2021-03-08 09:37:51 -07:00
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_for_each_worker(wq, io_wq_worker_wake, NULL);
|
2021-03-08 09:37:51 -07:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
io_worker_ref_put(wq);
|
2026-01-21 10:40:33 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Shut up hung task complaint, see for example
|
|
|
|
|
*
|
|
|
|
|
* https://lore.kernel.org/all/696fc9e7.a70a0220.111c58.0006.GAE@google.com/
|
|
|
|
|
*
|
|
|
|
|
* where completely overloading the system with tons of long running
|
|
|
|
|
* io-wq items can easily trigger the hung task timeout. Only sleep
|
|
|
|
|
* uninterruptibly for half that time, and warn if we exceeded end
|
|
|
|
|
* up waiting more than IO_URING_EXIT_WAIT_MAX.
|
|
|
|
|
*/
|
|
|
|
|
timeout = sysctl_hung_task_timeout_secs * HZ / 2;
|
2026-01-23 13:58:03 -07:00
|
|
|
if (!timeout)
|
|
|
|
|
timeout = MAX_SCHEDULE_TIMEOUT;
|
2026-01-21 10:40:33 -07:00
|
|
|
warn_timeout = jiffies + IO_URING_EXIT_WAIT_MAX;
|
|
|
|
|
do {
|
|
|
|
|
if (wait_for_completion_timeout(&wq->worker_done, timeout))
|
|
|
|
|
break;
|
|
|
|
|
WARN_ON_ONCE(time_after(jiffies, warn_timeout));
|
|
|
|
|
} while (1);
|
2021-05-26 13:08:26 +08:00
|
|
|
|
2023-03-10 12:11:07 -08:00
|
|
|
spin_lock_irq(&wq->hash->wait.lock);
|
2023-03-21 22:16:28 -03:00
|
|
|
list_del_init(&wq->wait.entry);
|
2023-03-10 12:11:07 -08:00
|
|
|
spin_unlock_irq(&wq->hash->wait.lock);
|
|
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
put_task_struct(wq->task);
|
|
|
|
|
wq->task = NULL;
|
2021-02-26 13:48:19 -07:00
|
|
|
}
|
|
|
|
|
|
2021-02-25 10:17:09 -07:00
|
|
|
static void io_wq_destroy(struct io_wq *wq)
|
2019-10-22 10:25:58 -06:00
|
|
|
{
|
2023-03-10 12:11:07 -08:00
|
|
|
struct io_cb_cancel_data match = {
|
|
|
|
|
.fn = io_wq_work_match_all,
|
|
|
|
|
.cancel_all = true,
|
|
|
|
|
};
|
2019-10-22 10:25:58 -06:00
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
cpuhp_state_remove_instance_nocalls(io_wq_online, &wq->cpuhp_node);
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_cancel_pending_work(wq, &match);
|
|
|
|
|
free_cpumask_var(wq->cpu_mask);
|
2021-02-19 12:33:30 -07:00
|
|
|
io_wq_put_hash(wq->hash);
|
2019-10-22 10:25:58 -06:00
|
|
|
kfree(wq);
|
2021-02-25 10:17:09 -07:00
|
|
|
}
|
|
|
|
|
|
2021-02-26 13:48:19 -07:00
|
|
|
void io_wq_put_and_exit(struct io_wq *wq)
|
|
|
|
|
{
|
2021-05-23 15:48:39 +01:00
|
|
|
WARN_ON_ONCE(!test_bit(IO_WQ_BIT_EXIT, &wq->state));
|
|
|
|
|
|
2021-03-08 09:37:51 -07:00
|
|
|
io_wq_exit_workers(wq);
|
2021-06-14 02:36:13 +01:00
|
|
|
io_wq_destroy(wq);
|
2021-02-26 13:48:19 -07:00
|
|
|
}
|
|
|
|
|
|
2021-06-17 10:08:11 -06:00
|
|
|
struct online_data {
|
|
|
|
|
unsigned int cpu;
|
|
|
|
|
bool online;
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
static bool io_wq_worker_affinity(struct io_worker *worker, void *data)
|
|
|
|
|
{
|
2021-06-17 10:08:11 -06:00
|
|
|
struct online_data *od = data;
|
2020-10-22 09:02:50 -06:00
|
|
|
|
2021-06-17 10:08:11 -06:00
|
|
|
if (od->online)
|
2023-03-21 22:16:28 -03:00
|
|
|
cpumask_set_cpu(od->cpu, worker->wq->cpu_mask);
|
2021-06-17 10:08:11 -06:00
|
|
|
else
|
2023-03-21 22:16:28 -03:00
|
|
|
cpumask_clear_cpu(od->cpu, worker->wq->cpu_mask);
|
2020-10-22 09:02:50 -06:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-17 10:08:11 -06:00
|
|
|
static int __io_wq_cpu_online(struct io_wq *wq, unsigned int cpu, bool online)
|
|
|
|
|
{
|
|
|
|
|
struct online_data od = {
|
|
|
|
|
.cpu = cpu,
|
|
|
|
|
.online = online
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2023-03-21 22:16:28 -03:00
|
|
|
io_wq_for_each_worker(wq, io_wq_worker_affinity, &od);
|
2021-06-17 10:08:11 -06:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
static int io_wq_cpu_online(unsigned int cpu, struct hlist_node *node)
|
|
|
|
|
{
|
|
|
|
|
struct io_wq *wq = hlist_entry_safe(node, struct io_wq, cpuhp_node);
|
|
|
|
|
|
2021-06-17 10:08:11 -06:00
|
|
|
return __io_wq_cpu_online(wq, cpu, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int io_wq_cpu_offline(unsigned int cpu, struct hlist_node *node)
|
|
|
|
|
{
|
|
|
|
|
struct io_wq *wq = hlist_entry_safe(node, struct io_wq, cpuhp_node);
|
|
|
|
|
|
|
|
|
|
return __io_wq_cpu_online(wq, cpu, false);
|
2020-10-22 09:02:50 -06:00
|
|
|
}
|
|
|
|
|
|
2023-08-13 11:05:36 -06:00
|
|
|
int io_wq_cpu_affinity(struct io_uring_task *tctx, cpumask_var_t mask)
|
2021-06-17 10:19:54 -06:00
|
|
|
{
|
2024-09-10 19:11:56 +02:00
|
|
|
cpumask_var_t allowed_mask;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
2023-08-13 11:05:36 -06:00
|
|
|
if (!tctx || !tctx->io_wq)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2024-09-10 19:11:56 +02:00
|
|
|
if (!alloc_cpumask_var(&allowed_mask, GFP_KERNEL))
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2021-06-17 10:19:54 -06:00
|
|
|
rcu_read_lock();
|
2024-09-10 19:11:56 +02:00
|
|
|
cpuset_cpus_allowed(tctx->io_wq->task, allowed_mask);
|
|
|
|
|
if (mask) {
|
|
|
|
|
if (cpumask_subset(mask, allowed_mask))
|
|
|
|
|
cpumask_copy(tctx->io_wq->cpu_mask, mask);
|
|
|
|
|
else
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
} else {
|
|
|
|
|
cpumask_copy(tctx->io_wq->cpu_mask, allowed_mask);
|
|
|
|
|
}
|
2021-06-17 10:19:54 -06:00
|
|
|
rcu_read_unlock();
|
2023-03-10 12:11:07 -08:00
|
|
|
|
2024-09-10 19:11:56 +02:00
|
|
|
free_cpumask_var(allowed_mask);
|
|
|
|
|
return ret;
|
2021-06-17 10:19:54 -06:00
|
|
|
}
|
|
|
|
|
|
2021-08-27 11:33:19 -06:00
|
|
|
/*
|
|
|
|
|
* Set max number of unbounded workers, returns old value. If new_count is 0,
|
|
|
|
|
* then just return the old value.
|
|
|
|
|
*/
|
|
|
|
|
int io_wq_max_workers(struct io_wq *wq, int *new_count)
|
|
|
|
|
{
|
2023-03-21 22:16:27 -03:00
|
|
|
struct io_wq_acct *acct;
|
2021-11-02 12:32:08 -06:00
|
|
|
int prev[IO_WQ_ACCT_NR];
|
2023-03-10 12:11:07 -08:00
|
|
|
int i;
|
2021-08-27 11:33:19 -06:00
|
|
|
|
2021-09-13 17:44:15 +02:00
|
|
|
BUILD_BUG_ON((int) IO_WQ_ACCT_BOUND != (int) IO_WQ_BOUND);
|
|
|
|
|
BUILD_BUG_ON((int) IO_WQ_ACCT_UNBOUND != (int) IO_WQ_UNBOUND);
|
|
|
|
|
BUILD_BUG_ON((int) IO_WQ_ACCT_NR != 2);
|
|
|
|
|
|
2022-02-06 17:52:41 +08:00
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++) {
|
2021-08-27 11:33:19 -06:00
|
|
|
if (new_count[i] > task_rlimit(current, RLIMIT_NPROC))
|
|
|
|
|
new_count[i] = task_rlimit(current, RLIMIT_NPROC);
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-02 12:32:08 -06:00
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++)
|
|
|
|
|
prev[i] = 0;
|
|
|
|
|
|
2021-08-27 11:33:19 -06:00
|
|
|
rcu_read_lock();
|
|
|
|
|
|
2023-03-10 12:11:07 -08:00
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++) {
|
2023-03-21 22:16:27 -03:00
|
|
|
acct = &wq->acct[i];
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_lock(&acct->workers_lock);
|
2023-03-10 12:11:07 -08:00
|
|
|
prev[i] = max_t(int, acct->max_workers, prev[i]);
|
|
|
|
|
if (new_count[i])
|
|
|
|
|
acct->max_workers = new_count[i];
|
2025-01-28 14:39:22 +01:00
|
|
|
raw_spin_unlock(&acct->workers_lock);
|
2021-08-27 11:33:19 -06:00
|
|
|
}
|
|
|
|
|
rcu_read_unlock();
|
2021-11-02 12:32:08 -06:00
|
|
|
|
|
|
|
|
for (i = 0; i < IO_WQ_ACCT_NR; i++)
|
|
|
|
|
new_count[i] = prev[i];
|
|
|
|
|
|
2021-08-27 11:33:19 -06:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-22 09:02:50 -06:00
|
|
|
static __init int io_wq_init(void)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "io-wq/online",
|
2021-06-17 10:08:11 -06:00
|
|
|
io_wq_cpu_online, io_wq_cpu_offline);
|
2020-10-22 09:02:50 -06:00
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
io_wq_online = ret;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
subsys_initcall(io_wq_init);
|