Re: [RFC 0/9] fixed worker: a new way to handle io works

[Pavel Begunkov <asml.silence@gmail.com>]

On 11/24/21 04:46, Hao Xu wrote:
> There is big contension in current io-wq implementation. Introduce a new
> type io-worker called fixed-worker to solve this problem. it is also a
> new way to handle works. In this new system, works are dispatched to
> different private queues rather than a long shared queue.

It's really great to temper the contention here, even though it looks
we are stepping onto the path of reinventing all the optimisations
solved long ago in other thread pools. Work stealing is probably
the next, but guess it's inevitable :)

First four patchhes sound like a good idea, they will probably go
first. However, IIUC, the hashing is crucial and it's a must have.
Are you planning to add it? If not, is there an easy way to leave
hashing working even if hashed reqs not going through those new
per-worker queues? E.g. (if it's not already as this...)

if (hashed) {
	// fixed workers don't support hashing, so go through the
	// old path and place into the shared queue.
	enqueue_shared_queue();
} else
	enqueue_new_path();

And last note, just fyi, it's easier to sell patches if you put
numbers in the cover letter


> Hao Xu (9):
>    io-wq: decouple work_list protection from the big wqe->lock
>    io-wq: reduce acct->lock crossing functions lock/unlock
>    io-wq: update check condition for lock
>    io-wq: use IO_WQ_ACCT_NR rather than hardcoded number
>    io-wq: move hash wait entry to io_wqe_acct
>    io-wq: add infra data structure for fix workers
>    io-wq: implement fixed worker logic
>    io-wq: batch the handling of fixed worker private works
>    io-wq: small optimization for __io_worker_busy()
> 
>   fs/io-wq.c | 415 ++++++++++++++++++++++++++++++++++++++---------------
>   fs/io-wq.h |   5 +
>   2 files changed, 308 insertions(+), 112 deletions(-)
> 

-- 
Pavel Begunkov