2019-10-22 19:25:58 +03: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 18:02:50 +03:00
# include <linux/cpu.h>
2022-02-09 21:47:08 +03:00
# include <linux/task_work.h>
2021-02-17 03:46:48 +03:00
# include <linux/audit.h>
2023-03-10 23:11:07 +03:00
# include <linux/mmu_context.h>
2021-09-13 18:44:15 +03:00
# include <uapi/linux/io_uring.h>
2019-10-22 19:25:58 +03:00
# include "io-wq.h"
2022-06-21 12:09:01 +03:00
# include "slist.h"
2022-06-21 12:09:02 +03:00
# include "io_uring.h"
2019-10-22 19:25:58 +03:00
# define WORKER_IDLE_TIMEOUT (5 * HZ)
enum {
IO_WORKER_F_UP = 1 , /* up and active */
IO_WORKER_F_RUNNING = 2 , /* account as running */
IO_WORKER_F_FREE = 4 , /* worker on free list */
2021-09-01 22:01:17 +03:00
IO_WORKER_F_BOUND = 8 , /* is doing bounded work */
2019-10-22 19:25:58 +03:00
} ;
enum {
IO_WQ_BIT_EXIT = 0 , /* wq exiting */
} ;
enum {
2021-08-31 22:57:32 +03:00
IO_ACCT_STALLED_BIT = 0 , /* stalled on hash */
2019-10-22 19:25:58 +03:00
} ;
/*
2023-03-22 04:16:28 +03:00
* One for each thread in a wq pool
2019-10-22 19:25:58 +03:00
*/
struct io_worker {
refcount_t ref ;
unsigned flags ;
struct hlist_nulls_node nulls_node ;
2019-11-13 23:54:49 +03:00
struct list_head all_list ;
2019-10-22 19:25:58 +03:00
struct task_struct * task ;
2023-03-22 04:16:28 +03:00
struct io_wq * wq ;
2019-11-13 19:43:34 +03:00
2019-10-22 19:25:58 +03:00
struct io_wq_work * cur_work ;
2022-01-19 05:23:51 +03:00
struct io_wq_work * next_work ;
2022-01-19 05:13:43 +03:00
raw_spinlock_t lock ;
2019-10-22 19:25:58 +03:00
2021-02-24 05:59:06 +03: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 17:37:25 +03:00
unsigned long create_state ;
struct callback_head create_work ;
int create_index ;
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 20:20:10 +03:00
union {
struct rcu_head rcu ;
struct work_struct work ;
} ;
2019-10-22 19:25:58 +03: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-22 04:16:27 +03:00
struct io_wq_acct {
2019-11-07 21:41:16 +03:00
unsigned nr_workers ;
unsigned max_workers ;
2021-03-08 19:37:51 +03:00
int index ;
2019-11-07 21:41:16 +03:00
atomic_t nr_running ;
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 12:52:39 +03:00
raw_spinlock_t lock ;
2021-08-31 22:57:32 +03:00
struct io_wq_work_list work_list ;
unsigned long flags ;
2019-11-07 21:41:16 +03:00
} ;
enum {
IO_WQ_ACCT_BOUND ,
IO_WQ_ACCT_UNBOUND ,
2021-08-31 22:57:32 +03:00
IO_WQ_ACCT_NR ,
2019-11-07 21:41:16 +03:00
} ;
2019-10-22 19:25:58 +03:00
/*
* Per io_wq state
*/
struct io_wq {
unsigned long state ;
2020-03-04 16:14:12 +03:00
free_work_fn * free_work ;
2020-06-08 21:08:20 +03:00
io_wq_work_fn * do_work ;
2019-11-13 08:31:31 +03:00
2021-02-19 22:33:30 +03:00
struct io_wq_hash * hash ;
2021-02-26 19:47:20 +03:00
atomic_t worker_refs ;
struct completion worker_done ;
2020-10-22 18:02:50 +03:00
struct hlist_node cpuhp_node ;
2021-02-17 00:15:30 +03:00
2021-03-08 19:37:51 +03:00
struct task_struct * task ;
2021-06-14 04:36:12 +03:00
2023-03-22 04:16:27 +03:00
struct io_wq_acct acct [ IO_WQ_ACCT_NR ] ;
2023-03-22 04:16:28 +03:00
/* lock protects access to elements below */
raw_spinlock_t lock ;
struct hlist_nulls_head free_list ;
struct list_head all_list ;
struct wait_queue_entry wait ;
struct io_wq_work * hash_tail [ IO_WQ_NR_HASH_BUCKETS ] ;
cpumask_var_t cpu_mask ;
2019-10-22 19:25:58 +03:00
} ;
2020-10-22 18:02:50 +03:00
static enum cpuhp_state io_wq_online ;
2021-03-04 01:47:04 +03:00
struct io_cb_cancel_data {
work_cancel_fn * fn ;
void * data ;
int nr_running ;
int nr_pending ;
bool cancel_all ;
} ;
2023-03-22 04:16:28 +03:00
static bool create_io_worker ( struct io_wq * wq , int index ) ;
static void io_wq_dec_running ( struct io_worker * worker ) ;
static bool io_acct_cancel_pending_work ( struct io_wq * wq ,
2023-03-22 04: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 20:20:10 +03:00
struct io_cb_cancel_data * match ) ;
2021-10-29 15:11:33 +03:00
static void create_worker_cb ( struct callback_head * cb ) ;
2021-12-10 18:29:30 +03:00
static void io_wq_cancel_tw_create ( struct io_wq * wq ) ;
2021-03-04 01:47:04 +03:00
2019-10-22 19:25:58 +03: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-24 05:59:06 +03:00
complete ( & worker - > ref_done ) ;
2019-10-22 19:25:58 +03:00
}
2023-03-22 04:16:27 +03:00
static inline struct io_wq_acct * io_get_acct ( struct io_wq * wq , bool bound )
2021-03-22 04:58:28 +03:00
{
2023-03-22 04:16:27 +03:00
return & wq - > acct [ bound ? IO_WQ_ACCT_BOUND : IO_WQ_ACCT_UNBOUND ] ;
2021-03-22 04:58:28 +03:00
}
2023-03-22 04:16:27 +03:00
static inline struct io_wq_acct * io_work_get_acct ( struct io_wq * wq ,
struct io_wq_work * work )
2019-11-07 21:41:16 +03:00
{
2023-03-22 04:16:27 +03:00
return io_get_acct ( wq , ! ( work - > flags & IO_WQ_WORK_UNBOUND ) ) ;
2019-11-07 21:41:16 +03:00
}
2023-03-22 04:16:27 +03:00
static inline struct io_wq_acct * io_wq_get_acct ( struct io_worker * worker )
2019-11-07 21:41:16 +03:00
{
2023-03-22 04:16:28 +03:00
return io_get_acct ( worker - > wq , worker - > flags & IO_WORKER_F_BOUND ) ;
2019-11-07 21:41:16 +03:00
}
2021-03-08 19:37:51 +03: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 15:50:07 +03: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 15:11:33 +03:00
static void io_worker_cancel_cb ( struct io_worker * worker )
{
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = io_wq_get_acct ( worker ) ;
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2021-10-29 15:11:33 +03:00
atomic_dec ( & acct - > nr_running ) ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2021-10-29 15:11:33 +03:00
acct - > nr_workers - - ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-10-29 15:11:33 +03: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 19:25:58 +03:00
static void io_worker_exit ( struct io_worker * worker )
{
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2019-10-22 19:25:58 +03:00
2021-10-29 15:11:33 +03: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 19:25:58 +03:00
2021-10-23 14:13:55 +03:00
io_worker_release ( worker ) ;
2021-02-24 05:59:06 +03:00
wait_for_completion ( & worker - > ref_done ) ;
2019-10-22 19:25:58 +03:00
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2021-08-03 18:14:35 +03:00
if ( worker - > flags & IO_WORKER_F_FREE )
2021-02-17 04:00:55 +03:00
hlist_nulls_del_rcu ( & worker - > nulls_node ) ;
2019-11-13 23:54:49 +03:00
list_del_rcu ( & worker - > all_list ) ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
io_wq_dec_running ( worker ) ;
2023-06-14 04:26:55 +03: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 19:25:58 +03:00
2019-11-02 10:55:01 +03:00
kfree_rcu ( worker , rcu ) ;
2023-03-22 04:16:28 +03:00
io_worker_ref_put ( wq ) ;
2021-03-04 22:39:36 +03:00
do_exit ( 0 ) ;
2019-10-22 19:25:58 +03:00
}
2023-08-09 21:59:40 +03:00
static inline bool __io_acct_run_queue ( struct io_wq_acct * acct )
2019-11-07 21:41:16 +03:00
{
2023-08-09 21:59:40 +03:00
return ! test_bit ( IO_ACCT_STALLED_BIT , & acct - > flags ) & &
! wq_list_empty ( & acct - > work_list ) ;
}
2022-02-06 12:52:40 +03:00
2023-08-09 21:59:40 +03: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 12:52:40 +03:00
raw_spin_lock ( & acct - > lock ) ;
2023-08-09 21:59:40 +03:00
if ( __io_acct_run_queue ( acct ) )
return true ;
2022-02-06 12:52:40 +03:00
2023-08-09 21:59:40 +03:00
raw_spin_unlock ( & acct - > lock ) ;
return false ;
2019-11-07 21:41:16 +03:00
}
/*
* Check head of free list for an available worker . If one isn ' t available ,
2021-03-08 19:37:51 +03:00
* caller must create one .
2019-11-07 21:41:16 +03:00
*/
2023-03-22 04:16:28 +03:00
static bool io_wq_activate_free_worker ( struct io_wq * wq ,
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct )
2019-11-07 21:41:16 +03:00
__must_hold ( RCU )
{
struct hlist_nulls_node * n ;
struct io_worker * worker ;
2021-08-03 18:14:35 +03: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 .
*/
2023-03-22 04:16:28 +03:00
hlist_nulls_for_each_entry_rcu ( worker , n , & wq - > free_list , nulls_node ) {
2021-08-03 18:14:35 +03:00
if ( ! io_worker_get ( worker ) )
continue ;
2023-03-22 04:16:27 +03:00
if ( io_wq_get_acct ( worker ) ! = acct ) {
2021-08-31 22:57:32 +03:00
io_worker_release ( worker ) ;
continue ;
}
2023-08-09 22:07:54 +03: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 21:41:16 +03:00
io_worker_release ( worker ) ;
2023-08-09 22:07:54 +03:00
return true ;
2019-11-07 21:41:16 +03:00
}
return false ;
}
/*
* We need a worker . If we find a free one , we ' re good . If not , and we ' re
2021-03-08 19:37:51 +03:00
* below the max number of workers , create one .
2019-11-07 21:41:16 +03:00
*/
2023-03-22 04:16:28 +03:00
static bool io_wq_create_worker ( struct io_wq * wq , struct io_wq_acct * acct )
2019-11-07 21:41:16 +03:00
{
/*
* Most likely an attempt to queue unbounded work on an io_wq that
* wasn ' t setup with any unbounded workers .
*/
2021-06-17 20:13:59 +03:00
if ( unlikely ( ! acct - > max_workers ) )
pr_warn_once ( " io-wq is not configured for unbound workers " ) ;
2019-11-07 21:41:16 +03:00
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2021-10-19 22:31:26 +03:00
if ( acct - > nr_workers > = acct - > max_workers ) {
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-09-11 22:40:50 +03:00
return true ;
2021-08-30 20:55:22 +03:00
}
2021-09-11 22:40:50 +03:00
acct - > nr_workers + + ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-09-11 22:40:50 +03:00
atomic_inc ( & acct - > nr_running ) ;
2023-03-22 04:16:28 +03:00
atomic_inc ( & wq - > worker_refs ) ;
return create_io_worker ( wq , acct - > index ) ;
2019-11-07 21:41:16 +03:00
}
2023-03-22 04:16:28 +03:00
static void io_wq_inc_running ( struct io_worker * worker )
2019-11-07 21:41:16 +03:00
{
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = io_wq_get_acct ( worker ) ;
2019-11-07 21:41:16 +03:00
atomic_inc ( & acct - > nr_running ) ;
}
2021-03-08 19:37:51 +03: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 17:37:25 +03:00
struct io_worker * worker ;
2021-03-08 19:37:51 +03:00
struct io_wq * wq ;
2023-03-22 04:16:28 +03:00
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct ;
2021-09-01 22:01:17 +03:00
bool do_create = false ;
2021-03-08 19:37:51 +03: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 17:37:25 +03:00
worker = container_of ( cb , struct io_worker , create_work ) ;
2023-03-22 04:16:28 +03:00
wq = worker - > wq ;
2023-03-22 04:16:27 +03:00
acct = & wq - > acct [ worker - > create_index ] ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2021-08-08 16:54:33 +03:00
if ( acct - > nr_workers < acct - > max_workers ) {
2021-08-05 13:05:38 +03:00
acct - > nr_workers + + ;
2021-08-08 16:54:33 +03:00
do_create = true ;
}
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-08-08 16:54:33 +03:00
if ( do_create ) {
2023-03-22 04:16:28 +03:00
create_io_worker ( wq , worker - > create_index ) ;
2021-08-08 16:54:33 +03:00
} else {
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 17:37:25 +03:00
clear_bit_unlock ( 0 , & worker - > create_state ) ;
io_worker_release ( worker ) ;
2021-03-08 19:37:51 +03: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 20:20:10 +03:00
static bool io_queue_worker_create ( struct io_worker * worker ,
2023-03-22 04: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 20:20:10 +03:00
task_work_func_t func )
2021-03-08 19:37:51 +03:00
{
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2021-03-08 19:37:51 +03: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 17:37:25 +03: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 19:37:51 +03:00
2021-12-10 18:29:30 +03: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 20:20:10 +03:00
init_task_work ( & worker - > create_work , func ) ;
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 17:37:25 +03:00
worker - > create_index = acct - > index ;
2021-12-10 18:29:30 +03: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 20:20:10 +03:00
return true ;
2021-12-10 18:29:30 +03: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 17:37:25 +03:00
clear_bit_unlock ( 0 , & worker - > create_state ) ;
fail_release :
io_worker_release ( worker ) ;
2021-03-08 19:37:51 +03: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 20:20:10 +03:00
return false ;
2021-03-08 19:37:51 +03:00
}
2023-03-22 04:16:28 +03:00
static void io_wq_dec_running ( struct io_worker * worker )
2019-11-07 21:41:16 +03:00
{
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = io_wq_get_acct ( worker ) ;
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2019-11-07 21:41:16 +03:00
2021-03-08 19:37:51 +03:00
if ( ! ( worker - > flags & IO_WORKER_F_UP ) )
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 12:52:39 +03:00
if ( ! atomic_dec_and_test ( & acct - > nr_running ) )
return ;
2022-02-06 12:52:40 +03: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 12:52:39 +03:00
return ;
2023-08-09 21:59:40 +03: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 12:52:39 +03:00
atomic_inc ( & acct - > nr_running ) ;
2023-03-22 04: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 12:52:39 +03:00
io_queue_worker_create ( worker , acct , create_worker_cb ) ;
2019-11-07 21:41:16 +03:00
}
2019-10-22 19:25:58 +03:00
/*
* Worker will start processing some work . Move it to the busy list , if
* it ' s currently on the freelist
*/
2023-03-22 04:16:28 +03:00
static void __io_worker_busy ( struct io_wq * wq , struct io_worker * worker )
2019-10-22 19:25:58 +03:00
{
if ( worker - > flags & IO_WORKER_F_FREE ) {
worker - > flags & = ~ IO_WORKER_F_FREE ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2019-10-22 19:25:58 +03:00
hlist_nulls_del_init_rcu ( & worker - > nulls_node ) ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2019-10-22 19:25:58 +03:00
}
}
/*
2023-03-27 22:10:21 +03:00
* No work , worker going to sleep . Move to freelist .
2019-10-22 19:25:58 +03:00
*/
2023-03-22 04:16:28 +03:00
static void __io_worker_idle ( struct io_wq * wq , struct io_worker * worker )
__must_hold ( wq - > lock )
2019-10-22 19:25:58 +03:00
{
if ( ! ( worker - > flags & IO_WORKER_F_FREE ) ) {
worker - > flags | = IO_WORKER_F_FREE ;
2023-03-22 04:16:28 +03:00
hlist_nulls_add_head_rcu ( & worker - > nulls_node , & wq - > free_list ) ;
2019-10-22 19:25:58 +03:00
}
}
2020-03-14 00:31:05 +03:00
static inline unsigned int io_get_work_hash ( struct io_wq_work * work )
{
return work - > flags > > IO_WQ_HASH_SHIFT ;
}
2023-03-22 04:16:28 +03:00
static bool io_wait_on_hash ( struct io_wq * wq , unsigned int hash )
2021-02-19 22:33:30 +03:00
{
2021-11-12 03:32:53 +03:00
bool ret = false ;
2021-02-19 22:33:30 +03:00
2021-08-31 15:57:25 +03:00
spin_lock_irq ( & wq - > hash - > wait . lock ) ;
2023-03-22 04:16:28 +03:00
if ( list_empty ( & wq - > wait . entry ) ) {
__add_wait_queue ( & wq - > hash - > wait , & wq - > wait ) ;
2021-02-19 22:33:30 +03:00
if ( ! test_bit ( hash , & wq - > hash - > map ) ) {
__set_current_state ( TASK_RUNNING ) ;
2023-03-22 04:16:28 +03:00
list_del_init ( & wq - > wait . entry ) ;
2021-11-12 03:32:53 +03:00
ret = true ;
2021-02-19 22:33:30 +03:00
}
}
2021-08-31 15:57:25 +03:00
spin_unlock_irq ( & wq - > hash - > wait . lock ) ;
2021-11-12 03:32:53 +03:00
return ret ;
2021-02-19 22:33:30 +03:00
}
2023-03-22 04:16:27 +03:00
static struct io_wq_work * io_get_next_work ( struct io_wq_acct * acct ,
2021-08-31 22:53:00 +03:00
struct io_worker * worker )
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 12:52:39 +03:00
__must_hold ( acct - > lock )
2019-10-22 19:25:58 +03:00
{
2019-11-26 21:59:32 +03: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 22:33:30 +03:00
unsigned int stall_hash = - 1U ;
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2019-10-22 19:25:58 +03:00
2021-08-31 22:57:32 +03:00
wq_list_for_each ( node , prev , & acct - > work_list ) {
2021-02-19 22:33:30 +03:00
unsigned int hash ;
2019-11-26 21:59:32 +03:00
work = container_of ( node , struct io_wq_work , list ) ;
2019-10-22 19:25:58 +03:00
/* not hashed, can run anytime */
2020-03-14 00:31:04 +03:00
if ( ! io_wq_is_hashed ( work ) ) {
2021-08-31 22:57:32 +03:00
wq_list_del ( & acct - > work_list , node , prev ) ;
2019-10-22 19:25:58 +03:00
return work ;
}
2020-03-14 00:31:05 +03:00
hash = io_get_work_hash ( work ) ;
2021-02-19 22:33:30 +03:00
/* all items with this hash lie in [work, tail] */
2023-03-22 04:16:28 +03:00
tail = wq - > hash_tail [ hash ] ;
2021-02-19 22:33:30 +03:00
/* hashed, can run if not already running */
2023-03-22 04:16:28 +03:00
if ( ! test_and_set_bit ( hash , & wq - > hash - > map ) ) {
wq - > hash_tail [ hash ] = NULL ;
2021-08-31 22:57:32 +03:00
wq_list_cut ( & acct - > work_list , & tail - > list , prev ) ;
2019-10-22 19:25:58 +03:00
return work ;
}
2021-02-19 22:33:30 +03: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-12 03:32:53 +03:00
bool unstalled ;
2021-08-31 22:53:00 +03:00
/*
* Set this before dropping the lock to avoid racing with new
* work being added and clearing the stalled bit .
*/
2021-08-31 22:57:32 +03: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 12:52:39 +03:00
raw_spin_unlock ( & acct - > lock ) ;
2023-03-22 04: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 12:52:39 +03:00
raw_spin_lock ( & acct - > lock ) ;
2021-11-12 03:32:53 +03:00
if ( unstalled ) {
clear_bit ( IO_ACCT_STALLED_BIT , & acct - > flags ) ;
2023-03-22 04:16:28 +03:00
if ( wq_has_sleeper ( & wq - > hash - > wait ) )
wake_up ( & wq - > hash - > wait ) ;
2021-11-12 03:32:53 +03:00
}
2019-10-22 19:25:58 +03: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 12:09:02 +03: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-19 05:13:43 +03:00
raw_spin_lock ( & worker - > lock ) ;
2020-03-04 16:14:09 +03:00
worker - > cur_work = work ;
2022-01-19 05:23:51 +03:00
worker - > next_work = NULL ;
2022-01-19 05:13:43 +03:00
raw_spin_unlock ( & worker - > lock ) ;
2020-03-04 16:14:09 +03:00
}
2023-08-09 21:59:40 +03: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 19:25:58 +03:00
{
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2021-04-08 03:54:42 +03:00
bool do_kill = test_bit ( IO_WQ_BIT_EXIT , & wq - > state ) ;
2019-10-22 19:25:58 +03:00
do {
2020-03-23 22:57:22 +03:00
struct io_wq_work * work ;
2022-01-19 23:11:58 +03:00
2019-10-22 19:25:58 +03: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 .
*/
2021-08-31 22:57:32 +03:00
work = io_get_next_work ( acct , worker ) ;
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 12:52:39 +03:00
raw_spin_unlock ( & acct - > lock ) ;
2022-01-19 05:23:51 +03:00
if ( work ) {
2023-03-22 04:16:28 +03:00
__io_worker_busy ( wq , worker ) ;
2019-10-22 19:25:58 +03:00
2022-01-19 05:23:51 +03:00
/*
* 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 ) ;
worker - > next_work = work ;
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 12:52:39 +03:00
} else {
2019-10-22 19:25:58 +03:00
break ;
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 12:52:39 +03:00
}
2020-03-04 16:14:10 +03:00
io_assign_current_work ( worker , work ) ;
2021-02-19 22:33:30 +03:00
__set_current_state ( TASK_RUNNING ) ;
2019-11-13 19:43:34 +03:00
2020-03-04 16:14:09 +03:00
/* handle a whole dependent link */
do {
2021-02-04 16:52:08 +03:00
struct io_wq_work * next_hashed , * linked ;
2020-07-25 14:42:00 +03:00
unsigned int hash = io_get_work_hash ( work ) ;
2020-03-04 16:14:09 +03:00
2020-03-23 22:57:22 +03:00
next_hashed = wq_next_work ( work ) ;
2021-04-08 03:54:42 +03:00
if ( unlikely ( do_kill ) & & ( work - > flags & IO_WQ_WORK_UNBOUND ) )
work - > flags | = IO_WQ_WORK_CANCEL ;
2021-02-04 16:52:08 +03:00
wq - > do_work ( work ) ;
io_assign_current_work ( worker , NULL ) ;
2020-03-04 16:14:09 +03:00
2021-02-04 16:52:08 +03:00
linked = 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-22 04:16:28 +03:00
io_wq_enqueue ( wq , linked ) ;
2020-03-23 22:57:22 +03:00
if ( hash ! = - 1U & & ! next_hashed ) {
2021-11-12 03:32:53 +03:00
/* serialize hash clear with wake_up() */
spin_lock_irq ( & wq - > hash - > wait . lock ) ;
2021-02-19 22:33:30 +03:00
clear_bit ( hash , & wq - > hash - > map ) ;
2021-08-31 22:57:32 +03:00
clear_bit ( IO_ACCT_STALLED_BIT , & acct - > flags ) ;
2021-11-12 03:32:53 +03:00
spin_unlock_irq ( & wq - > hash - > wait . lock ) ;
2021-02-19 22:33:30 +03:00
if ( wq_has_sleeper ( & wq - > hash - > wait ) )
wake_up ( & wq - > hash - > wait ) ;
2019-11-13 08:31:31 +03:00
}
2020-03-04 16:14:10 +03:00
} while ( work ) ;
2023-08-09 21:59:40 +03:00
if ( ! __io_acct_run_queue ( acct ) )
break ;
raw_spin_lock ( & acct - > lock ) ;
2019-10-22 19:25:58 +03:00
} while ( 1 ) ;
}
2023-03-22 04:16:28 +03:00
static int io_wq_worker ( void * data )
2019-10-22 19:25:58 +03:00
{
struct io_worker * worker = data ;
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = io_wq_get_acct ( worker ) ;
2023-03-22 04:16:28 +03:00
struct io_wq * wq = worker - > wq ;
2023-03-08 17:18:51 +03:00
bool exit_mask = false , last_timeout = false ;
2021-03-04 22:39:36 +03:00
char buf [ TASK_COMM_LEN ] ;
2019-10-22 19:25:58 +03:00
2021-03-04 22:39:36 +03:00
worker - > flags | = ( IO_WORKER_F_UP | IO_WORKER_F_RUNNING ) ;
2021-03-08 19:37:51 +03:00
snprintf ( buf , sizeof ( buf ) , " iou-wrk-%d " , wq - > task - > pid ) ;
2021-03-04 22:39:36 +03:00
set_task_comm ( current , buf ) ;
2019-10-22 19:25:58 +03:00
while ( ! test_bit ( IO_WQ_BIT_EXIT , & wq - > state ) ) {
2021-03-13 06:26:13 +03:00
long ret ;
2019-12-08 07:03:59 +03:00
set_current_state ( TASK_INTERRUPTIBLE ) ;
2023-08-09 21:59:40 +03: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 12:52:40 +03:00
while ( io_acct_run_queue ( acct ) )
2023-08-09 21:59:40 +03:00
io_worker_handle_work ( acct , worker ) ;
2022-02-06 12:52:40 +03:00
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2023-03-08 17:18:51 +03:00
/*
* Last sleep timed out . Exit if we ' re not the last worker ,
* or if someone modified our affinity .
*/
if ( last_timeout & & ( exit_mask | | acct - > nr_workers > 1 ) ) {
2021-09-11 22:40:52 +03:00
acct - > nr_workers - - ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-09-01 22:01:17 +03:00
__set_current_state ( TASK_RUNNING ) ;
break ;
}
last_timeout = false ;
2023-03-22 04:16:28 +03:00
__io_worker_idle ( wq , worker ) ;
raw_spin_unlock ( & wq - > lock ) ;
2022-06-21 12:09:02 +03:00
if ( io_run_task_work ( ) )
2021-03-21 16:06:56 +03:00
continue ;
2021-03-13 06:26:13 +03:00
ret = schedule_timeout ( WORKER_IDLE_TIMEOUT ) ;
2021-03-26 03:16:06 +03:00
if ( signal_pending ( current ) ) {
struct ksignal ksig ;
if ( ! get_signal ( & ksig ) )
continue ;
2021-09-27 19:04:10 +03:00
break ;
2021-03-26 03:16:06 +03:00
}
2023-03-08 17:18:51 +03:00
if ( ! ret ) {
last_timeout = true ;
exit_mask = ! cpumask_test_cpu ( raw_smp_processor_id ( ) ,
2023-03-22 04:16:28 +03:00
wq - > cpu_mask ) ;
2023-03-08 17:18:51 +03:00
}
2019-10-22 19:25:58 +03:00
}
2023-08-09 21:59:40 +03:00
if ( test_bit ( IO_WQ_BIT_EXIT , & wq - > state ) & & io_acct_run_queue ( acct ) )
io_worker_handle_work ( acct , worker ) ;
2019-10-22 19:25:58 +03: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-23 07:10:09 +03:00
struct io_worker * worker = tsk - > worker_private ;
2019-10-22 19:25:58 +03:00
2021-02-17 00:15:30 +03:00
if ( ! worker )
return ;
2019-10-22 19:25:58 +03:00
if ( ! ( worker - > flags & IO_WORKER_F_UP ) )
return ;
if ( worker - > flags & IO_WORKER_F_RUNNING )
return ;
worker - > flags | = IO_WORKER_F_RUNNING ;
2023-03-22 04:16:28 +03:00
io_wq_inc_running ( worker ) ;
2019-10-22 19:25:58 +03:00
}
/*
* Called when worker is going to sleep . If there are no workers currently
2021-03-08 19:37:51 +03:00
* running and we have work pending , wake up a free one or create a new one .
2019-10-22 19:25:58 +03:00
*/
void io_wq_worker_sleeping ( struct task_struct * tsk )
{
2021-12-23 07:10:09 +03:00
struct io_worker * worker = tsk - > worker_private ;
2019-10-22 19:25:58 +03:00
2021-02-17 00:15:30 +03:00
if ( ! worker )
return ;
2019-10-22 19:25:58 +03:00
if ( ! ( worker - > flags & IO_WORKER_F_UP ) )
return ;
if ( ! ( worker - > flags & IO_WORKER_F_RUNNING ) )
return ;
worker - > flags & = ~ IO_WORKER_F_RUNNING ;
2023-03-22 04:16:28 +03:00
io_wq_dec_running ( worker ) ;
2019-10-22 19:25:58 +03:00
}
2023-03-22 04:16:28 +03:00
static void io_init_new_worker ( struct io_wq * wq , 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 20:20:10 +03:00
struct task_struct * tsk )
{
2021-12-23 07:10:09 +03:00
tsk - > worker_private = 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 20:20:10 +03:00
worker - > task = tsk ;
2023-03-22 04:16:28 +03:00
set_cpus_allowed_ptr ( tsk , wq - > cpu_mask ) ;
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 20:20:10 +03:00
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
hlist_nulls_add_head_rcu ( & worker - > nulls_node , & wq - > free_list ) ;
list_add_tail_rcu ( & worker - > all_list , & wq - > all_list ) ;
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 20:20:10 +03:00
worker - > flags | = IO_WORKER_F_FREE ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > 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 20:20:10 +03:00
wake_up_new_task ( tsk ) ;
}
static bool io_wq_work_match_all ( struct io_wq_work * work , void * data )
{
return true ;
}
static inline bool io_should_retry_thread ( long err )
{
2021-12-03 05:40:15 +03:00
/*
* Prevent perpetual task_work retry , if the task ( or its group ) is
* exiting .
*/
if ( fatal_signal_pending ( current ) )
return false ;
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 20:20:10 +03:00
switch ( err ) {
case - EAGAIN :
case - ERESTARTSYS :
case - ERESTARTNOINTR :
case - ERESTARTNOHAND :
return true ;
default :
return false ;
}
}
static void create_worker_cont ( struct callback_head * cb )
{
struct io_worker * worker ;
struct task_struct * tsk ;
2023-03-22 04:16:28 +03:00
struct io_wq * 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 20:20:10 +03:00
worker = container_of ( cb , struct io_worker , create_work ) ;
clear_bit_unlock ( 0 , & worker - > create_state ) ;
2023-03-22 04:16:28 +03:00
wq = worker - > wq ;
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 20:20:10 +03:00
if ( ! IS_ERR ( tsk ) ) {
2023-03-22 04:16:28 +03:00
io_init_new_worker ( wq , 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 20:20:10 +03:00
io_worker_release ( worker ) ;
return ;
} else if ( ! io_should_retry_thread ( PTR_ERR ( tsk ) ) ) {
2023-03-22 04: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 20:20:10 +03:00
atomic_dec ( & acct - > nr_running ) ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > 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 20:20:10 +03:00
acct - > nr_workers - - ;
if ( ! acct - > nr_workers ) {
struct io_cb_cancel_data match = {
. fn = io_wq_work_match_all ,
. cancel_all = true ,
} ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
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 12:52:39 +03:00
;
} else {
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > 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 20:20:10 +03:00
}
2023-03-22 04:16:28 +03:00
io_worker_ref_put ( wq ) ;
2021-09-09 14:58:22 +03: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 20:20:10 +03:00
return ;
}
/* re-create attempts grab a new worker ref, drop the existing one */
io_worker_release ( worker ) ;
schedule_work ( & worker - > work ) ;
}
static void io_workqueue_create ( struct work_struct * work )
{
struct io_worker * worker = container_of ( work , struct io_worker , work ) ;
2023-03-22 04: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 20:20:10 +03:00
2021-09-11 11:58:47 +03:00
if ( ! io_queue_worker_create ( worker , acct , create_worker_cont ) )
2021-09-09 14:58:22 +03: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 20:20:10 +03:00
}
2023-03-22 04:16:28 +03:00
static bool create_io_worker ( struct io_wq * wq , int index )
2021-02-17 00:15:30 +03:00
{
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = & wq - > acct [ index ] ;
2021-02-17 00:15:30 +03:00
struct io_worker * worker ;
2021-03-04 22:39:36 +03:00
struct task_struct * tsk ;
2021-02-17 00:15:30 +03:00
2021-02-24 01:34:06 +03:00
__set_current_state ( TASK_RUNNING ) ;
2023-03-10 23:11:07 +03:00
worker = kzalloc ( sizeof ( * worker ) , GFP_KERNEL ) ;
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 20:20:10 +03:00
if ( ! worker ) {
2021-03-08 19:37:51 +03:00
fail :
atomic_dec ( & acct - > nr_running ) ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2021-08-05 13:05:37 +03:00
acct - > nr_workers - - ;
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-03-08 19:37:51 +03:00
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 20:20:10 +03:00
return false ;
2021-02-17 00:15:30 +03:00
}
2021-03-04 22:39:36 +03: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 20:20:10 +03:00
refcount_set ( & worker - > ref , 1 ) ;
2023-03-22 04:16:28 +03:00
worker - > wq = wq ;
2022-01-19 05:13:43 +03: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 20:20:10 +03:00
init_completion ( & worker - > ref_done ) ;
2021-03-04 22:39:36 +03:00
if ( index = = IO_WQ_ACCT_BOUND )
worker - > flags | = IO_WORKER_F_BOUND ;
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 20:20:10 +03:00
2023-03-22 04: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 20:20:10 +03:00
if ( ! IS_ERR ( tsk ) ) {
2023-03-22 04:16:28 +03:00
io_init_new_worker ( wq , 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 20:20:10 +03:00
} else if ( ! io_should_retry_thread ( PTR_ERR ( tsk ) ) ) {
2021-09-09 14:58:22 +03: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 20:20:10 +03:00
goto fail ;
} else {
INIT_WORK ( & worker - > work , io_workqueue_create ) ;
schedule_work ( & worker - > work ) ;
}
return true ;
2019-10-22 19:25:58 +03:00
}
2020-09-26 16:26:55 +03:00
/*
* Iterate the passed in list and call the specific function for each
* worker that isn ' t exiting
*/
2023-03-22 04:16:28 +03:00
static bool io_wq_for_each_worker ( struct io_wq * wq ,
2020-09-26 16:26:55 +03:00
bool ( * func ) ( struct io_worker * , void * ) ,
void * data )
{
struct io_worker * worker ;
bool ret = false ;
2023-03-22 04:16:28 +03:00
list_for_each_entry_rcu ( worker , & wq - > all_list , all_list ) {
2020-09-26 16:26:55 +03: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 ;
}
static bool io_wq_worker_wake ( struct io_worker * worker , void * data )
{
2022-04-26 04:49:01 +03:00
__set_notify_signal ( worker - > task ) ;
2020-09-26 16:26:55 +03:00
wake_up_process ( worker - > task ) ;
return false ;
}
2023-03-22 04: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 {
work - > flags | = IO_WQ_WORK_CANCEL ;
2021-02-04 16:52:08 +03:00
wq - > do_work ( work ) ;
work = wq - > free_work ( work ) ;
2020-03-01 19:18:19 +03:00
} while ( work ) ;
}
2023-03-22 04:16:28 +03:00
static void io_wq_insert_work ( struct io_wq * wq , struct io_wq_work * work )
2020-03-23 22:57:22 +03:00
{
2023-03-22 04:16:28 +03:00
struct io_wq_acct * acct = io_work_get_acct ( wq , work ) ;
2020-03-23 22:57:22 +03:00
unsigned int hash ;
struct io_wq_work * tail ;
if ( ! io_wq_is_hashed ( work ) ) {
append :
2021-08-31 22:57:32 +03:00
wq_list_add_tail ( & work - > list , & acct - > work_list ) ;
2020-03-23 22:57:22 +03:00
return ;
}
hash = io_get_work_hash ( work ) ;
2023-03-22 04: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 22:57:32 +03:00
wq_list_add_after ( & work - > list , & tail - > list , & acct - > work_list ) ;
2020-03-23 22:57:22 +03:00
}
2021-09-08 12:09:29 +03:00
static bool io_wq_work_match_item ( struct io_wq_work * work , void * data )
{
return work = = data ;
}
2023-03-22 04:16:28 +03:00
void io_wq_enqueue ( struct io_wq * wq , struct io_wq_work * work )
2019-10-22 19:25:58 +03:00
{
2023-03-22 04:16:28 +03:00
struct io_wq_acct * acct = io_work_get_acct ( wq , 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 12:52:39 +03:00
struct io_cb_cancel_data match ;
2021-08-30 20:55:22 +03:00
unsigned work_flags = work - > flags ;
bool do_create ;
2019-10-22 19:25:58 +03:00
2021-07-23 20:53:54 +03: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-22 04:16:28 +03:00
if ( test_bit ( IO_WQ_BIT_EXIT , & wq - > state ) | |
2021-07-23 20:53:54 +03:00
( work - > flags & IO_WQ_WORK_CANCEL ) ) {
2023-03-22 04:16:28 +03:00
io_run_cancel ( work , wq ) ;
2021-02-25 20:17:09 +03: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 12:52:39 +03:00
raw_spin_lock ( & acct - > lock ) ;
2023-03-22 04:16:28 +03:00
io_wq_insert_work ( wq , work ) ;
2021-08-31 22:57:32 +03: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 12:52:39 +03:00
raw_spin_unlock ( & acct - > lock ) ;
2021-08-30 20:55:22 +03:00
rcu_read_lock ( ) ;
2023-03-22 04:16:28 +03:00
do_create = ! io_wq_activate_free_worker ( wq , acct ) ;
2021-08-30 20:55:22 +03: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 20:20:10 +03:00
! atomic_read ( & acct - > nr_running ) ) ) {
bool did_create ;
2023-03-22 04:16:28 +03:00
did_create = io_wq_create_worker ( wq , acct ) ;
2021-09-08 12:09:29 +03:00
if ( likely ( did_create ) )
return ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > 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 12:52:39 +03:00
if ( acct - > nr_workers ) {
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > 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 12:52:39 +03: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 20:20:10 +03:00
}
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > 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 12:52:39 +03:00
/* fatal condition, failed to create the first worker */
match . fn = io_wq_work_match_item ,
match . data = work ,
match . cancel_all = false ,
2023-03-22 04: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 20:20:10 +03:00
}
2019-10-22 19:25:58 +03: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 19:25:58 +03:00
*/
2020-03-14 00:31:04 +03:00
void io_wq_hash_work ( struct io_wq_work * work , void * val )
2019-10-22 19:25:58 +03:00
{
2020-03-14 00:31:04 +03:00
unsigned int bit ;
2019-10-22 19:25:58 +03:00
bit = hash_ptr ( val , IO_WQ_HASH_ORDER ) ;
work - > flags | = ( IO_WQ_WORK_HASHED | ( bit < < IO_WQ_HASH_SHIFT ) ) ;
}
2022-01-19 05:23:51 +03: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 ) ) {
work - > flags | = IO_WQ_WORK_CANCEL ;
2022-04-26 04:49:01 +03:00
__set_notify_signal ( worker - > task ) ;
2022-01-19 05:23:51 +03: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-29 06:49:21 +03:00
{
2020-03-07 01:15:39 +03:00
struct io_cb_cancel_data * match = data ;
2019-10-29 06:49:21 +03:00
/*
* Hold the lock to avoid - > cur_work going out of scope , caller
2019-11-13 19:43:34 +03:00
* may dereference the passed in work .
2019-10-29 06:49:21 +03:00
*/
2022-01-19 05:13:43 +03:00
raw_spin_lock ( & worker - > lock ) ;
2022-01-19 05:23:51 +03:00
if ( __io_wq_worker_cancel ( worker , match , worker - > cur_work ) | |
__io_wq_worker_cancel ( worker , match , worker - > next_work ) )
2020-06-15 10:24:03 +03:00
match - > nr_running + + ;
2022-01-19 05:13:43 +03:00
raw_spin_unlock ( & worker - > lock ) ;
2019-10-22 19:25:58 +03:00
2020-06-15 10:24:03 +03:00
return match - > nr_running & & ! match - > cancel_all ;
2019-10-22 19:25:58 +03:00
}
2023-03-22 04:16:28 +03:00
static inline void io_wq_remove_pending ( struct io_wq * wq ,
2020-08-23 20:33:10 +03:00
struct io_wq_work * work ,
struct io_wq_work_node * prev )
{
2023-03-22 04:16:28 +03:00
struct io_wq_acct * acct = io_work_get_acct ( wq , work ) ;
2020-08-23 20:33:10 +03:00
unsigned int hash = io_get_work_hash ( work ) ;
struct io_wq_work * prev_work = NULL ;
2023-03-22 04: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 ) ;
if ( prev_work & & io_get_work_hash ( prev_work ) = = hash )
2023-03-22 04:16:28 +03:00
wq - > hash_tail [ hash ] = prev_work ;
2020-08-23 20:33:10 +03:00
else
2023-03-22 04:16:28 +03:00
wq - > hash_tail [ hash ] = NULL ;
2020-08-23 20:33:10 +03:00
}
2021-08-31 22:57:32 +03:00
wq_list_del ( & acct - > work_list , & work - > list , prev ) ;
2020-08-23 20:33:10 +03:00
}
2023-03-22 04:16:28 +03:00
static bool io_acct_cancel_pending_work ( struct io_wq * wq ,
2023-03-22 04: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 20:20:10 +03:00
struct io_cb_cancel_data * match )
2019-10-22 19:25:58 +03:00
{
2019-11-26 21:59:32 +03:00
struct io_wq_work_node * node , * prev ;
2019-10-22 19:25:58 +03: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 12:52:39 +03: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 20:20:10 +03: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 ;
2023-03-22 04:16:28 +03:00
io_wq_remove_pending ( wq , 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 12:52:39 +03:00
raw_spin_unlock ( & acct - > lock ) ;
2023-03-22 04: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 20:20:10 +03: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 12:52:39 +03: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 20:20:10 +03:00
return false ;
}
2023-03-22 04:16:28 +03:00
static void io_wq_cancel_pending_work ( struct io_wq * wq ,
2023-03-22 04: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 20:20:10 +03:00
{
int i ;
2020-06-15 10:24:03 +03:00
retry :
2021-08-31 22:57:32 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + ) {
2023-03-22 04: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-22 04: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 20:20:10 +03:00
if ( match - > cancel_all )
goto retry ;
2022-01-19 05:18:20 +03:00
break ;
2021-08-31 22:57:32 +03:00
}
2019-10-22 19:25:58 +03:00
}
2020-06-15 10:24:02 +03:00
}
2023-03-22 04: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 19:25:58 +03:00
rcu_read_lock ( ) ;
2023-03-22 04:16:28 +03:00
io_wq_for_each_worker ( wq , io_wq_worker_cancel , match ) ;
2019-10-22 19:25:58 +03: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 )
2019-10-22 19:25:58 +03:00
{
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-02-09 05:13:32 +03:00
} ;
2019-10-22 19:25:58 +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-19 05:22:32 +03: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-19 05:22:32 +03:00
*
2023-03-22 04:16:28 +03:00
* Do both of these while holding the wq - > lock , to ensure that
2022-01-19 05:22:32 +03:00
* we ' ll find a work item regardless of state .
2020-06-15 10:24:02 +03:00
*/
2023-03-22 04:16:28 +03:00
io_wq_cancel_pending_work ( wq , & match ) ;
2023-03-10 23:11:07 +03:00
if ( match . nr_pending & & ! match . cancel_all )
return IO_WQ_CANCEL_OK ;
2022-01-19 05:22:32 +03:00
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
io_wq_cancel_running_work ( wq , & match ) ;
raw_spin_unlock ( & wq - > lock ) ;
2023-03-10 23:11:07 +03: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 ;
2019-10-22 19:25:58 +03:00
}
2023-03-22 04:16:28 +03:00
static int io_wq_hash_wake ( struct wait_queue_entry * wait , unsigned mode ,
2021-02-19 22:33:30 +03:00
int sync , void * key )
{
2023-03-22 04:16:28 +03:00
struct io_wq * wq = container_of ( wait , struct io_wq , wait ) ;
2021-08-31 22:57:32 +03:00
int i ;
2021-02-19 22:33:30 +03:00
list_del_init ( & wait - > entry ) ;
rcu_read_lock ( ) ;
2021-08-31 22:57:32 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + ) {
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = & wq - > acct [ i ] ;
2021-08-31 22:57:32 +03:00
if ( test_and_clear_bit ( IO_ACCT_STALLED_BIT , & acct - > flags ) )
2023-03-22 04:16:28 +03:00
io_wq_activate_free_worker ( wq , acct ) ;
2021-08-31 22:57:32 +03:00
}
2021-02-19 22:33:30 +03:00
rcu_read_unlock ( ) ;
return 1 ;
}
2019-11-25 18:49:20 +03:00
struct io_wq * io_wq_create ( unsigned bounded , struct io_wq_data * data )
2019-10-22 19:25:58 +03:00
{
2023-03-10 23:11:07 +03:00
int ret , i ;
2019-10-22 19:25:58 +03:00
struct io_wq * wq ;
2020-06-08 21:08:20 +03:00
if ( WARN_ON_ONCE ( ! data - > free_work | | ! data - > do_work ) )
2020-03-04 16:14:12 +03:00
return ERR_PTR ( - EINVAL ) ;
2021-06-17 20:13:59 +03:00
if ( WARN_ON_ONCE ( ! bounded ) )
return ERR_PTR ( - EINVAL ) ;
2020-03-04 16:14:12 +03:00
2023-03-10 23:11:07 +03:00
wq = kzalloc ( sizeof ( struct io_wq ) , GFP_KERNEL ) ;
2019-10-22 19:25:58 +03:00
if ( ! wq )
return ERR_PTR ( - ENOMEM ) ;
2021-02-19 22:33:30 +03:00
refcount_inc ( & data - > hash - > refs ) ;
wq - > hash = data - > hash ;
2020-03-04 16:14:12 +03:00
wq - > free_work = data - > free_work ;
2020-06-08 21:08:20 +03:00
wq - > do_work = data - > do_work ;
2019-11-13 08:31:31 +03:00
2020-10-22 18:02:50 +03:00
ret = - ENOMEM ;
2023-03-10 23:11:07 +03:00
2023-03-22 04:16:28 +03:00
if ( ! alloc_cpumask_var ( & wq - > cpu_mask , GFP_KERNEL ) )
2023-03-10 23:11:07 +03:00
goto err ;
2023-03-22 04:16:28 +03:00
cpumask_copy ( wq - > cpu_mask , cpu_possible_mask ) ;
2023-03-22 04:16:27 +03:00
wq - > acct [ IO_WQ_ACCT_BOUND ] . max_workers = bounded ;
wq - > acct [ IO_WQ_ACCT_UNBOUND ] . max_workers =
2023-03-10 23:11:07 +03:00
task_rlimit ( current , RLIMIT_NPROC ) ;
2023-03-22 04:16:28 +03:00
INIT_LIST_HEAD ( & wq - > wait . entry ) ;
wq - > wait . func = io_wq_hash_wake ;
2023-03-10 23:11:07 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + ) {
2023-03-22 04:16:27 +03:00
struct io_wq_acct * acct = & wq - > acct [ i ] ;
2023-03-10 23:11:07 +03:00
acct - > index = i ;
atomic_set ( & acct - > nr_running , 0 ) ;
INIT_WQ_LIST ( & acct - > work_list ) ;
raw_spin_lock_init ( & acct - > lock ) ;
2019-10-22 19:25:58 +03:00
}
2023-03-22 04:16:28 +03:00
raw_spin_lock_init ( & wq - > lock ) ;
INIT_HLIST_NULLS_HEAD ( & wq - > free_list , 0 ) ;
INIT_LIST_HEAD ( & wq - > all_list ) ;
2019-10-22 19:25:58 +03:00
2021-03-08 19:37:51 +03:00
wq - > task = get_task_struct ( data - > task ) ;
atomic_set ( & wq - > worker_refs , 1 ) ;
init_completion ( & wq - > worker_done ) ;
2023-10-05 20:55:31 +03:00
ret = cpuhp_state_add_instance_nocalls ( io_wq_online , & wq - > cpuhp_node ) ;
if ( ret )
goto err ;
2021-03-08 19:37:51 +03:00
return wq ;
2019-11-19 18:37:07 +03:00
err :
2021-03-01 19:09:56 +03:00
io_wq_put_hash ( data - > hash ) ;
2023-03-22 04:16:28 +03:00
free_cpumask_var ( wq - > cpu_mask ) ;
2019-11-19 18:37:07 +03:00
kfree ( wq ) ;
2019-10-22 19:25:58 +03:00
return ERR_PTR ( ret ) ;
}
2021-04-02 04:57:07 +03: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 17:37:25 +03:00
struct io_worker * worker ;
2021-04-02 04:57:07 +03:00
2021-09-09 04:57:26 +03:00
if ( cb - > func ! = create_worker_cb & & cb - > func ! = create_worker_cont )
2021-04-02 04:57:07 +03: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 17:37:25 +03:00
worker = container_of ( cb , struct io_worker , create_work ) ;
2023-03-22 04:16:28 +03:00
return worker - > wq = = data ;
2021-04-02 04:57:07 +03:00
}
2021-05-23 17:48:39 +03:00
void io_wq_exit_start ( struct io_wq * wq )
{
set_bit ( IO_WQ_BIT_EXIT , & wq - > state ) ;
}
2021-12-10 18:29:30 +03:00
static void io_wq_cancel_tw_create ( struct io_wq * wq )
2021-02-26 23:48:19 +03:00
{
2021-03-08 19:37:51 +03:00
struct callback_head * cb ;
2021-04-02 04:57:07 +03: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 17:37:25 +03:00
struct io_worker * worker ;
2021-03-08 19:37:51 +03: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 17:37:25 +03:00
worker = container_of ( cb , struct io_worker , create_work ) ;
2021-10-29 15:11:33 +03:00
io_worker_cancel_cb ( worker ) ;
2023-01-08 20:39:17 +03:00
/*
* Only the worker continuation helper has worker allocated and
* hence needs freeing .
*/
if ( cb - > func = = create_worker_cont )
kfree ( worker ) ;
2021-03-08 19:37:51 +03:00
}
2021-12-10 18:29:30 +03:00
}
static void io_wq_exit_workers ( struct io_wq * wq )
{
if ( ! wq - > task )
return ;
io_wq_cancel_tw_create ( wq ) ;
2021-03-08 19:37:51 +03:00
rcu_read_lock ( ) ;
2023-03-22 04:16:28 +03:00
io_wq_for_each_worker ( wq , io_wq_worker_wake , NULL ) ;
2021-03-08 19:37:51 +03:00
rcu_read_unlock ( ) ;
io_worker_ref_put ( wq ) ;
wait_for_completion ( & wq - > worker_done ) ;
2021-05-26 08:08:26 +03:00
2023-03-10 23:11:07 +03:00
spin_lock_irq ( & wq - > hash - > wait . lock ) ;
2023-03-22 04:16:28 +03:00
list_del_init ( & wq - > wait . entry ) ;
2023-03-10 23:11:07 +03:00
spin_unlock_irq ( & wq - > hash - > wait . lock ) ;
2021-03-08 19:37:51 +03:00
put_task_struct ( wq - > task ) ;
wq - > task = NULL ;
2021-02-26 23:48:19 +03:00
}
2021-02-25 20:17:09 +03:00
static void io_wq_destroy ( struct io_wq * wq )
2019-10-22 19:25:58 +03:00
{
2023-03-10 23:11:07 +03:00
struct io_cb_cancel_data match = {
. fn = io_wq_work_match_all ,
. cancel_all = true ,
} ;
2019-10-22 19:25:58 +03:00
2020-10-22 18:02:50 +03:00
cpuhp_state_remove_instance_nocalls ( io_wq_online , & wq - > cpuhp_node ) ;
2023-03-22 04:16:28 +03:00
io_wq_cancel_pending_work ( wq , & match ) ;
free_cpumask_var ( wq - > cpu_mask ) ;
2021-02-19 22:33:30 +03:00
io_wq_put_hash ( wq - > hash ) ;
2019-10-22 19:25:58 +03:00
kfree ( wq ) ;
2021-02-25 20:17:09 +03:00
}
2021-02-26 23:48:19 +03:00
void io_wq_put_and_exit ( struct io_wq * wq )
{
2021-05-23 17:48:39 +03:00
WARN_ON_ONCE ( ! test_bit ( IO_WQ_BIT_EXIT , & wq - > state ) ) ;
2021-03-08 19:37:51 +03:00
io_wq_exit_workers ( wq ) ;
2021-06-14 04:36:13 +03:00
io_wq_destroy ( wq ) ;
2021-02-26 23:48:19 +03:00
}
2021-06-17 19:08:11 +03:00
struct online_data {
unsigned int cpu ;
bool online ;
} ;
2020-10-22 18:02:50 +03:00
static bool io_wq_worker_affinity ( struct io_worker * worker , void * data )
{
2021-06-17 19:08:11 +03:00
struct online_data * od = data ;
2021-04-08 12:44:50 +03:00
2021-06-17 19:08:11 +03:00
if ( od - > online )
2023-03-22 04:16:28 +03:00
cpumask_set_cpu ( od - > cpu , worker - > wq - > cpu_mask ) ;
2021-06-17 19:08:11 +03:00
else
2023-03-22 04:16:28 +03:00
cpumask_clear_cpu ( od - > cpu , worker - > wq - > cpu_mask ) ;
2020-10-22 18:02:50 +03:00
return false ;
}
2021-06-17 19:08:11 +03:00
static int __io_wq_cpu_online ( struct io_wq * wq , unsigned int cpu , bool online )
2020-10-22 18:02:50 +03:00
{
2021-06-17 19:08:11 +03:00
struct online_data od = {
. cpu = cpu ,
. online = online
} ;
2020-10-22 18:02:50 +03:00
rcu_read_lock ( ) ;
2023-03-22 04:16:28 +03:00
io_wq_for_each_worker ( wq , io_wq_worker_affinity , & od ) ;
2020-10-22 18:02:50 +03:00
rcu_read_unlock ( ) ;
return 0 ;
}
2021-06-17 19:08:11 +03: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 ) ;
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 ) ;
}
2023-08-13 20:05:36 +03:00
int io_wq_cpu_affinity ( struct io_uring_task * tctx , cpumask_var_t mask )
2021-06-17 19:19:54 +03:00
{
2023-08-13 20:05:36 +03:00
if ( ! tctx | | ! tctx - > io_wq )
return - EINVAL ;
2021-06-17 19:19:54 +03:00
rcu_read_lock ( ) ;
2023-03-10 23:11:07 +03:00
if ( mask )
2023-08-13 20:05:36 +03:00
cpumask_copy ( tctx - > io_wq - > cpu_mask , mask ) ;
2023-03-10 23:11:07 +03:00
else
2023-08-13 20:05:36 +03:00
cpumask_copy ( tctx - > io_wq - > cpu_mask , cpu_possible_mask ) ;
2021-06-17 19:19:54 +03:00
rcu_read_unlock ( ) ;
2023-03-10 23:11:07 +03:00
2021-06-17 19:19:54 +03:00
return 0 ;
}
2021-08-27 20:33:19 +03: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-22 04:16:27 +03:00
struct io_wq_acct * acct ;
2021-11-02 21:32:08 +03:00
int prev [ IO_WQ_ACCT_NR ] ;
2023-03-10 23:11:07 +03:00
int i ;
2021-08-27 20:33:19 +03:00
2021-09-13 18:44:15 +03: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 12:52:41 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + ) {
2021-08-27 20:33:19 +03:00
if ( new_count [ i ] > task_rlimit ( current , RLIMIT_NPROC ) )
new_count [ i ] = task_rlimit ( current , RLIMIT_NPROC ) ;
}
2021-11-02 21:32:08 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + )
prev [ i ] = 0 ;
2021-08-27 20:33:19 +03:00
rcu_read_lock ( ) ;
2023-03-22 04:16:28 +03:00
raw_spin_lock ( & wq - > lock ) ;
2023-03-10 23:11:07 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + ) {
2023-03-22 04:16:27 +03:00
acct = & wq - > acct [ i ] ;
2023-03-10 23:11:07 +03:00
prev [ i ] = max_t ( int , acct - > max_workers , prev [ i ] ) ;
if ( new_count [ i ] )
acct - > max_workers = new_count [ i ] ;
2021-08-27 20:33:19 +03:00
}
2023-03-22 04:16:28 +03:00
raw_spin_unlock ( & wq - > lock ) ;
2021-08-27 20:33:19 +03:00
rcu_read_unlock ( ) ;
2021-11-02 21:32:08 +03:00
for ( i = 0 ; i < IO_WQ_ACCT_NR ; i + + )
new_count [ i ] = prev [ i ] ;
2021-08-27 20:33:19 +03:00
return 0 ;
}
2020-10-22 18:02:50 +03: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 19:08:11 +03:00
io_wq_cpu_online , io_wq_cpu_offline ) ;
2020-10-22 18:02:50 +03:00
if ( ret < 0 )
return ret ;
io_wq_online = ret ;
return 0 ;
}
subsys_initcall ( io_wq_init ) ;