From owner-freebsd-hackers Tue Sep 14 3:50: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id D94A7150BE for ; Tue, 14 Sep 1999 03:49:57 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id NAA34462; Tue, 14 Sep 1999 13:49:46 +0300 (EEST) (envelope-from will) To: nordwick@scam.xcf.berkeley.edu (Jayson Nordwick) Cc: hackers@freebsd.org Subject: Re: aio_* References: <19990914050240.40381.qmail@scam.xcf.berkeley.edu> From: Ville-Pertti Keinonen Date: 14 Sep 1999 13:49:45 +0300 In-Reply-To: nordwick@scam.xcf.berkeley.edu's message of "14 Sep 1999 08:03:55 +0300" Message-ID: <867lltix86.fsf@not.demophon.com> Lines: 32 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG nordwick@scam.xcf.berkeley.edu (Jayson Nordwick) writes: > While reading through (at least trying to... I wish there was some sort of > kernel documentation available, the entry fee is very high) the aio_* calls, > I had a few questions to clear up my understanding: > 1) Do they only work on files? The only implementation I see is in > the VFS layer. AIO is not in the VFS layer. The source file containing the implementation is improperly named. It works on any file descriptor that you could do the equivalent read(2)/write(2) calls on. > 2) It is my understanding that it uses an aio daemon running as a kernel > thread (the aio_daemon() call kind of give that one away). It seems as > if this can be almost entirely done in user space. More important to what > I am trying to do, it seems as if aio_* does not give peak latency > or throughput performace, since the aio_daemon has to compete for resources > along with all other processes. > Should aio_* be used for applications that have high performance > requirements? What does aio_* get you above having a seperate > thread pumping in/out data? The implementation in FreeBSD probably isn't a particularly efficient one. It should be faster than threads, though. You'll need fewer switches between user and kernel mode and synchronization is simpler. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message