Date: Tue, 18 Feb 2014 13:28:26 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Gleb Smirnoff <glebius@freebsd.org>, David Chisnall <theraven@freebsd.org>, current@freebsd.org Subject: Re: [CFT] new sendfile(2) Message-ID: <201402181328.26553.jhb@freebsd.org> In-Reply-To: <F56AE9A0-3649-4D4B-B8A5-1CFF3CC3B6B5@FreeBSD.org> References: <20140217111635.GL26785@glebius.int.ru> <F56AE9A0-3649-4D4B-B8A5-1CFF3CC3B6B5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, February 17, 2014 6:24:21 am David Chisnall wrote: > P.S. If aio() is creating a new thread per request, rather than scheduling them from a pool, then that is also likely a bug. The aio APIs were designed so that systems with DMA controllers could issue DMA requests in the syscall and return immediately, then trigger the notification in response to the DMA- finished interrupt. There shouldn't need to be any kernel threads created to do this... AIO uses a pool, but the requests are all done synchronously from that pool. While our low-level disk routines are async (e.g. GEOM etc.), the filesystem code above that generally is not. The aio code does have some special gunk in place for sockets (and I believe raw disk I/O) to make it truly async, but aio for files uses sychronous I/O from a pool of worker threads. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402181328.26553.jhb>