[lkml]   [2015]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH v4 0/4] block: loop: improve loop with AIO
Hi Guys,

There are about 3 advantages to use direct I/O and AIO on
read/write loop's backing file:

1) double cache can be avoided, then memory usage gets
decreased a lot

2) not like user space direct I/O, there isn't cost of
pinning pages

3) avoid context switch for obtaining good throughput
- in buffered file read, random I/O throughput is often obtained
only if they are submitted concurrently from lots of tasks; but for
sequential I/O, most of times they can be hit from page cache, so
concurrent submissions often introduce unnecessary context switch
and can't improve throughput much. There was such discussion[1]
to use non-blocking I/O to improve the problem for application.
- with direct I/O and AIO, concurrent submissions can be
avoided and random read throughput can't be affected meantime

So this patchset trys to improve loop via AIO, and about 45% memory
usage can be decreased, see detailed data in commit log of patch4,
also IO throughput isn't affected too.

- add detailed commit log for 'use kthread_work'
- allow userspace(sysfs, losetup) to decide if dio/aio is
used as suggested by Christoph and Dave Chinner
- only use dio if the backing block device's min io size
is 512 as pointed by Dave Chinner & Christoph

- based on Al's iov_iter work and Christoph's kiocb changes
- use kthread_work
- introduce IOCB_DONT_DIRTY_PAGE flag
- set QUEUE_FLAG_NOMERGES for loop's request queue
- remove 'extra' parameter to aio_kernel_alloc()
- try to avoid memory allcation inside queue req callback
- introduce 'use_mq' sysfs file for enabling kernel aio or disabling it
- link:
- improve failure path in aio_kernel_submit()

 \ /
  Last update: 2015-05-29 09:21    [W:0.067 / U:51.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site