From owner-freebsd-arch@freebsd.org Wed Jan 27 17:52:36 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC997A70223 for ; Wed, 27 Jan 2016 17:52:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE60118A for ; Wed, 27 Jan 2016 17:52:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 99EF4A70222; Wed, 27 Jan 2016 17:52:36 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99929A70221 for ; Wed, 27 Jan 2016 17:52:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B9411188 for ; Wed, 27 Jan 2016 17:52:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 90060B989; Wed, 27 Jan 2016 12:52:35 -0500 (EST) From: John Baldwin To: Adrian Chadd Cc: "freebsd-arch@freebsd.org" Subject: Re: Refactoring asynchronous I/O Date: Wed, 27 Jan 2016 09:23:56 -0800 Message-ID: <4442858.kLAljyq4HJ@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jan 2016 12:52:35 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 17:52:36 -0000 On Tuesday, January 26, 2016 07:17:33 PM Adrian Chadd wrote: > On 26 January 2016 at 17:39, John Baldwin wrote: > > [snip] > > > > > Note that binding the AIO support to a new fileop does mean that the AIO code > > now becomes mandatory (rather than optional). We could perhaps make the > > system calls continue to be optional if people really need that, but the guts > > of the code will now need to always be in the kernel. > > > > I'd like to hear what people think of this design. It needs some additional > > cleanup before it is a commit candidate (and I'll see if I can't split it up > > some more if we go this route). > > So this doesn't change the direct dispatch read/write to a block device, right? > That strategy path is pretty damned cheap. No, that is the physio code that could be moved to be devfs specific. However, by exposing the aio queueing point to the fileops directly it allows for other fileops to implement direct dispatch without having to expose internals to the AIO code. > Also, why's it become mandatory? I thought we had support for optional > fileops... Some fileops are optional in that not all file descriptors implement them (e.g. not all fileops can be monitored by kevent() or mmap()ed), however we do not support kldloading a fileop. If you leave soo_aio_queue() in sys_socket.c then the kernel would not link without vfs_aio.c since the socket aio routine needs things like aio_complete, etc. You could perhaps split the system calls themselves out of vfs_aio.c into a separate sys_aio.c and make that loadable, but that would be fairly small. It also seems fairly pointless. The module is loadable because it was experimental and unfinished when it was first implemented. The current version is certainly not perfect, but it is much further along than the original code from 1997. I know folks have used the current code in production. -- John Baldwin