From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Kleikamp Subject: Re: [PATCH 7/9] aio: add aio_kernel_() interface Date: Thu, 24 Jul 2014 10:16:19 -0500 Message-ID: <53D12343.8050507@oracle.com> References: <1406156130-15575-1-git-send-email-ming.lei@canonical.com> <1406156130-15575-8-git-send-email-ming.lei@canonical.com> <20140723231600.GE17798@lenny.home.zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jens Axboe , Linux Kernel Mailing List , Andrew Morton , Benjamin LaHaise , Alexander Viro , Linux FS Devel , open@kvack.org, list@kvack.org:AIO , Kent Overstreet To: Ming Lei , Zach Brown Return-path: In-Reply-To: Sender: owner-linux-aio@kvack.org List-Id: linux-fsdevel.vger.kernel.org On 07/23/2014 08:57 PM, Ming Lei wrote: > On Thu, Jul 24, 2014 at 7:16 AM, Zach Brown wrote: >> On Thu, Jul 24, 2014 at 06:55:28AM +0800, Ming Lei wrote: >>> From: Dave Kleikamp >>> >>> This adds an interface that lets kernel callers submit aio iocbs without >>> going through the user space syscalls. This lets kernel callers avoid >>> the management limits and overhead of the context. It will also let us >>> integrate aio operations with other kernel apis that the user space >>> interface doesn't have access to. >>> >>> This patch is based on Dave's posts in below links: >>> >>> https://lkml.org/lkml/2013/10/16/365 >>> https://groups.google.com/forum/#!topic/linux.kernel/l7mogGJZoKQ >> >> This was originally written a billion years ago when dinosaurs roamed >> the earth. Also, notably, before Kent and Ben reworked a bunch of the > > Not so far away, this patch is based on Dave's last version of V9, which > was posted in Oct, 2013, :-) Which was based on a much earlier patch from Zach. I regret that I left aio_kernel_submit entangled with aio_run_iocb when I reworked his patches. >> aio core. I'd want them to take a look at this patch to make sure that >> it doesn't rely on any assumptions that have changed. > > Looks I missed to Cc Ken, :-( > >> >>> +/* opcode values not exposed to user space */ >>> +enum { >>> + IOCB_CMD_READ_ITER = 0x10000, >>> + IOCB_CMD_WRITE_ITER = 0x10001, >>> +}; >> >> And I think the consensus was that this isn't good enough. Find a way >> to encode the kernel caller ops without polluting the uiocb cmd name >> space. > > That is easy, since the two cmd names are only for kernel AIO, whatever > should be OK, but looks I didn't see such comment. Agreed. These were added because the flags had been interpreted by aio_run_iocb(). I'm happy that is no longer the case. >> >> (I've now come to think that this entire approach of having loop use aio >> is misguided and that the way forward is to have dio consume what loop >> naturally produces -- bios, blk-mq rqs, whatever -- but I'm on to other > > Yes, that is what these patches are doing, and actually AIO's > model is a good match to driver's interface. Lots of drivers > use the asynchronous model(submit, complete, ...). > >> things these days.) > > At least, loop can improve its throughput much by kernel AIO > without big changes to fs/direct-io(attribute much to ITER_BVEC), > and vhost-scsi should benefit from it too. > > Thanks, > -- To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to majordomo@kvack.org. For more info on Linux AIO, see: http://www.kvack.org/aio/ Don't email: aart@kvack.org