[ATTEND][LSF/MM TOPIC] kernel AIO support and block loop device improvements

[ATTEND][LSF/MM TOPIC] kernel AIO support and block loop device improvements

[Maxim Patlasov]

Hello,

I would like to have a discussion about current state of kernel AIO - an 
interface that lets kernel callers submit aio iocbs without going 
through the user space syscalls. The patches implementing the feature 
were developed and sent to mailing lists many times by Zach Brown and 
Dave Kleikamp long while ago. Then, after LSF/MM 2014, Alexander Viro 
made significant progress wiring ITER_BVEC into VFS call paths. His 
efforts made adding support of kernel AIO much easier as was recently 
demonstrated by Ming Lei's patches converting loop driver to blk-mq, but 
for some reasons the feature is still out of tree. An interesting aspect 
of the problem to be discussed is blocking/nonblocking behavior of 
aio_kernel_submit: even if it blocks only in rare cases, the caller 
(e.g. loop driver) must always use a separate thread for processing - 
extra overhead that can be avoided.

Thanks,
Maxim

Re: [ATTEND][LSF/MM TOPIC] kernel AIO support and block loop device improvements

[Omar Sandoval]

On Thu, Dec 11, 2014 at 01:23:11PM -0800, Maxim Patlasov wrote:
> Hello,
> 
> I would like to have a discussion about current state of kernel AIO - an
> interface that lets kernel callers submit aio iocbs without going through
> the user space syscalls. The patches implementing the feature were developed
> and sent to mailing lists many times by Zach Brown and Dave Kleikamp long
> while ago. Then, after LSF/MM 2014, Alexander Viro made significant progress
> wiring ITER_BVEC into VFS call paths. His efforts made adding support of
> kernel AIO much easier as was recently demonstrated by Ming Lei's patches
> converting loop driver to blk-mq, but for some reasons the feature is still
> out of tree. An interesting aspect of the problem to be discussed is
> blocking/nonblocking behavior of aio_kernel_submit: even if it blocks only
> in rare cases, the caller (e.g. loop driver) must always use a separate
> thread for processing - extra overhead that can be avoided.
> 
> Thanks,
> Maxim
>
Just to chime in, there's also discussion of bringing in kernel AIO for
generic swapfile support (introduced for swap-over-NFS, in development
for BTRFS), so the feature has at least a couple of use cases already.

-- 
Omar