Date: Wed, 27 Jan 2016 09:23:56 -0800 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Refactoring asynchronous I/O Message-ID: <4442858.kLAljyq4HJ@ralph.baldwin.cx> In-Reply-To: <CAJ-Vmo=0ixXxO1uZTWA9=dUMTu2ULRji-vFPmct8Q=y3YdAP4g@mail.gmail.com> References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> <CAJ-Vmo=0ixXxO1uZTWA9=dUMTu2ULRji-vFPmct8Q=y3YdAP4g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, January 26, 2016 07:17:33 PM Adrian Chadd wrote: > On 26 January 2016 at 17:39, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4442858.kLAljyq4HJ>