io-wq: small threadpool implementation for io_uring
authorJens Axboe <axboe@kernel.dk>
Tue, 22 Oct 2019 16:25:58 +0000 (10:25 -0600)
committerJens Axboe <axboe@kernel.dk>
Tue, 29 Oct 2019 18:43:00 +0000 (12:43 -0600)
commit771b53d033e8663abdf59704806aa856b236dcdb
tree4b1d0bdf8a64787aed08b2e4992d20553d2b5888
parent95a1b3ff9a3e4ea2f26c4e802067d58831f415db
io-wq: small threadpool implementation for io_uring

This adds support for io-wq, a smaller and specialized thread pool
implementation. This is meant to replace workqueues for io_uring. Among
the reasons for this addition are:

- We can assign memory context smarter and more persistently if we
  manage the life time of threads.

- We can drop various work-arounds we have in io_uring, like the
  async_list.

- We can implement hashed work insertion, to manage concurrency of
  buffered writes without needing a) an extra workqueue, or b)
  needlessly making the concurrency of said workqueue very low
  which hurts performance of multiple buffered file writers.

- We can implement cancel through signals, for cancelling
  interruptible work like read/write (or send/recv) to/from sockets.

- We need the above cancel for being able to assign and use file tables
  from a process.

- We can implement a more thorough cancel operation in general.

- We need it to move towards a syslet/threadlet model for even faster
  async execution. For that we need to take ownership of the used
  threads.

This list is just off the top of my head. Performance should be the
same, or better, at least that's what I've seen in my testing. io-wq
supports basic NUMA functionality, setting up a pool per node.

io-wq hooks up to the scheduler schedule in/out just like workqueue
and uses that to drive the need for more/less workers.

Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
fs/Kconfig
fs/Makefile
fs/io-wq.c [new file with mode: 0644]
fs/io-wq.h [new file with mode: 0644]
include/linux/sched.h
kernel/sched/core.c