Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jan 2016 13:16:37 -0800
From:      John Baldwin <jhb@freebsd.org>
To:        Slawa Olhovchenkov <slw@zxy.spb.ru>
Cc:        arch@freebsd.org
Subject:   Re: Refactoring asynchronous I/O
Message-ID:  <3640314.Du7Q0QmH0W@ralph.baldwin.cx>
In-Reply-To: <20160127210420.GZ88527@zxy.spb.ru>
References:  <2793494.0Z1kBV82mT@ralph.baldwin.cx> <1723457.HAUy43H1XN@ralph.baldwin.cx> <20160127210420.GZ88527@zxy.spb.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, January 28, 2016 12:04:20 AM Slawa Olhovchenkov wrote:
> On Wed, Jan 27, 2016 at 09:52:12AM -0800, John Baldwin wrote:
> 
> > On Wednesday, January 27, 2016 01:52:05 PM Slawa Olhovchenkov wrote:
> > > On Tue, Jan 26, 2016 at 05:39:03PM -0800, John Baldwin wrote:
> > > 
> > > > The original motivation for my changes is to support efficient zero-copy
> > > > receive for TOE using Chelsio T4/T5 adapters.  However, read() is ill
> > > 
> > > I undertuns that not you work, but: what about (teoretical) async
> > > open/close/unlink/etc?
> > 
> > Implementing more asynchronous operations is orthogonal to this.  It
> > would perhaps be a bit simpler to implement these in the new model
> > since most of the logic would live in a vnode-specific aio_queue
> > method in vfs_vnops.c.  However, the current AIO approach is to add a
> > new system call for each async system call (e.g. aio_open()).  You
> > would then create an internal LIO opcode (e.g. LIO_OPEN).  The vnode
> > aio hook would then have to support LIO_OPEN requests and return the
> > opened fd via aio_complete().  Async stat / open might be nice for
> > network filesystems in particular.  I've known of programs forking
> > separate threads just to do open/fstat of NFS files to achieve the
> > equivalent of aio_open() / aio_stat().
> 
> Some problem exist for open()/unlink/rename/etc -- you can't use
> fd-related semantic.

Mmmm.  We have an aio_mlock().  aio_open() would require more of a special
case like aio_mlock().  It's still doable, but it would not go via the
fileop, yes.  fstat could go via the fileop, but a path-based stat would
be akin to aio_open().

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3640314.Du7Q0QmH0W>