From owner-freebsd-hackers Fri Jun 22 21:15:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 9743F37B401 for ; Fri, 22 Jun 2001 21:15:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.143.225.Dial1.SanJose1.Level3.net [209.245.143.225]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id VAA02478; Fri, 22 Jun 2001 21:15:21 -0700 (PDT) Message-ID: <3B3417F9.2BC0CA3A@mindspring.com> Date: Fri, 22 Jun 2001 21:15:53 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "E.B. Dreger" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: question: aio / nbio / kqueue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "E.B. Dreger" wrote: > > Quick question, hopefully not too basic for this list: > > AIO vs. non-blocking IO vs. kernel queues > > I'm familiar with (and *love*) kernel queues. Non-blocking IO is > straightforward. AIO seems simple enough. > > My question is, from a performance standpoint, in what situations are > these techniques most appropriate? AIO allows I/O requests to be overlapped. None of the others do that. AIO bears the most resemblence to kernel threads (but is better), in that it permits you to have multiple outstanding blocking operations pending at the same time. Non-blocking I/O allows other work to be done, when there is no I/O available to do, instead of stalling everything until an attempted I/O completes. It is not very useful, if your program is I/O instead of compute bound, and/or the I/O pipeline for at least one descriptor is not always full. It also has high system call overhead. Kernel queues permit you to be notified via an event when some condition is true; this means that, unlike non-blocking I/O, you only do system calls when it would be useful to do system calls. They can also monitor kernel conditions, such as descriptor readability, the completion of AIO, etc.; since you only get an event when a condition you care about doing work as a result of exists, they significantly reduce system call overhead, as well as I/O overhead. In VMS terms: Blocking I/O: SYS$QIOW AIO: SYS$QIO + AST specified Non-blocking I/O: SYS$QIO + No AST specified Kernel queues: SYS$WAITEVFLOR ...and everything old is new again. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message