Mm/filemap.c | 35 ++++-Ģ files changed, 41 insertions(+), 31 deletions(-)ĭiff -git a/include/linux/pagemap.h b/include/linux/pagemap.h No functional changes in this patch, just in preparation for allowing ` (10 subsequent siblings) 13 siblings, 2 replies 68+ messages in thread 19:51 ` mm: add support for async page locking Jens Axboe
19:51 ` mm: allow read-ahead with IOCB_NOWAIT set Jens 19:51 ` Jens Axboe 19:51 Add support for async buffered reads Jens Axboe * mm: abstract out wake_page_match() from wake_page_function() +++ -2031,8 +2031,6 static ssize_t generic_file_buffered_read(struct kiocb *iocb, To: io-uring +Cc: linux-fsdevel, linux-kernel, linux-mm, akpm, Jens AxboeĪs read-ahead is opportunistic, don't block for request allocation.ġ file changed, 2 insertions(+), 1 deletion(-)ĭiff -git a/include/linux/blk_types.h b/include/linux/blk_types.h ` (12 subsequent siblings) 13 siblings, 0 replies 68+ messages in thread 19:51 ` mm: allow read-ahead with IOCB_NOWAIT set Jens Axboe 19:51 Add support for async buffered reads Jens 19:51 ` Jens Axboe * block: read-ahead submission should imply no-wait as well Fix a hang related to not setting page_match, thus missing a wakeup Fix a potential race with _wait_on_page_locked_async() Add another prep handler, adding wake_page_match() Get rid of unnecessary wait_page_async struct, just use wait_page_async Add iocb->ki_waitq instead of (ab)using iocb->private io_uring: alloc req->io if the request type didn't already io_uring: don't retry if REQ_F_NOWAIT is set Get rid of io_uring goto, use an iter read helper Correct commit message, iocb->private -> iocb->ki_waitq Have X threads hammering on the same inode page cache, we have justīeen beating on this and it's solid for me, and I'm now pretty happy By allowing proper async buffered read support, we don't It also adds noticable overhead on items such as adding pages to the Offload adds a blocking thread per pending IO, so context rate quickly Switch rate, which is massively lower with the new code. Before that happens, it's a linear increase. NVMe isn't veryĮfficient virtualized, so we run out of steam at ~65K which is why weįlatline on the patched side (nvme_submit_cmd() eats ~75% of the test appĬPU). NVMe device in qemu, using ext4 as the file system. Outside of my usual environment, so this is just running on a virtualized Switch rate is much smaller with the patchset, since we only have theĪlso ran a simple fio based test case, varying the queue depth from 1 Run, this includes the app itself and all the threads doing IO on itsīehalf (32% for the app, ~1.6% per worker and 32 of them). The CPU numbers are just a rough estimate. Use the more optimized buffered async read. If you want to test yourself, you can just use buffered=1 Of data in 4K chunks from a file hosted by ext4. In terms of results, I wrote a small test app that randomly reads 4G The file flags support for this by setting FMODE_BUF_RASYNC, similar XFS/ext4/btrfs/bdev is wired up, but probably Generic_file_buffered_read(), which is what most file systems end up With this callback primitive, we can add support for The callersĬallback is responsible for restarting the operation. Needed, -EIOCBQUEUED is returned with a callback armed. With io_uring, this works a lot like poll based Implemented with a thread backend to support cases where we wouldĪfter a few prep patches, the core of this patchset is adding supportįor async callbacks on page unlock. We technically support this already through io_uring, but it's To: io-uring +Cc: linux-fsdevel, linux-kernel, linux-mm, akpm ` (13 more replies) 0 siblings, 14 replies 68+ messages in thread
19:51 ` block: read-ahead submission should imply no-wait as well Jens Axboe
#ELAN SMART PAD DRIVER WINDOWS 8.1 SYSTEM76 ARCHIVE#
Add support for async buffered reads LKML Archive on help / color / mirror / Atom feed * Add support for async buffered reads 19:51 Jens Axboe
0 kommentar(er)
