diff options
author | Jens Axboe <axboe@kernel.dk> | 2019-10-22 10:25:58 -0600 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2019-10-29 12:43:00 -0600 |
commit | 771b53d033e8663abdf59704806aa856b236dcdb (patch) | |
tree | 4b1d0bdf8a64787aed08b2e4992d20553d2b5888 /init | |
parent | 95a1b3ff9a3e4ea2f26c4e802067d58831f415db (diff) |
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>
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions