Date: Fri, 5 Feb 2016 22:32:12 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Refactoring asynchronous I/O Message-ID: <20160205213212.GA97435@stack.nl> In-Reply-To: <9227739.EqUaAQ57pU@ralph.baldwin.cx> References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> <20160131230214.GA37435@stack.nl> <9227739.EqUaAQ57pU@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 05, 2016 at 12:21:52PM -0800, John Baldwin wrote: > On Monday, February 01, 2016 12:02:14 AM Jilles Tjoelker wrote: > > On Tue, Jan 26, 2016 at 05:39:03PM -0800, John Baldwin wrote: > > > 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. > > Enabling this by default is OK with me as long as the easy ways to get a > > stuck process are at least disabled by default. Currently, a process > > gets stuck forever if it has an AIO request from or to a pipe that will > > never complete. An AIO daemon should not be allowed to perform an > > unbounded sleep such as for a pipe (NFS server should be OK). > One thing I could do is split vfs_aio.c into two files: kern_aio.c that > holds the "library" such as aio_aqueue() / aio_complete(), etc. and a > sys_aio.c that is just the system calls. kern_aio.c would be standard, > but sys_aio.c could still be optional and aio.ko would contain it. > This would still make AIO optional, though aio.ko would be fairly small, > so not having it probably wouldn't save much in terms of size. > Does this seem reasonable or is a trivial aio.ko not worth it? It is one possible option. Another option is to refuse AIO for kinds of file that have not been vetted to avoid blocking an AIO daemon for too long. "Kinds of file" is about the code that will be executed to do I/O, so that, for example, /dev/klog and /dev/ttyv0 are different kinds. Depending on whether this restriction breaks existing code, it may need to be a sysctl. I don't expect a full AIO implementation for all kinds of file any time soon, so putting AIO syscalls into a kernel module will still leave the standard system without AIO for a long time, while still paying for the footprint of the AIO code. All of this would not be a problem if PCATCH worked in AIO daemons (treat aio_cancel like a pending signal in a user process) but the last time I looked this appeared quite hard to fix. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160205213212.GA97435>