Date: Mon, 01 Feb 2016 12:14:28 -0800 From: John Baldwin <jhb@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: arch@freebsd.org Subject: Re: Refactoring asynchronous I/O Message-ID: <4485804.9PRGDHMp0I@ralph.baldwin.cx> In-Reply-To: <20160131230214.GA37435@stack.nl> References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> <20160131230214.GA37435@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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). Mmm, I don't currently fix this for pipes, but my changes do fix this for sockets (right now if you queue multiple reads for a socket both are woken up when data arrives and if the data only satifies the first read request, the second will block an AIO daemon forever). However, having fo_aio_queue() should make this fixable for pipes as they could use their own queueing logic and handling function. It may be that pipes need to work more like sockets (where the handling is object-centric rather than request-centric, so a pipe would queue a task when it was ready and would drain any requests queued to that pipe). Pipes could either share the same AIO daemon pool as sockets or use a private pool. I'd probably like to avoid an explosion of daemon pools though. I considered having a single AIO pool, but it's kind of messy to keep the per-process job limits in the request-centric pool while also permitting object-centric handlers on the internal job queue. OTOH, if enough backends end up using object-centric handlers then the job limits might end up meaningless and we could just drop them. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4485804.9PRGDHMp0I>