Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jun 2001 21:15:53 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: question: aio / nbio / kqueue
Message-ID:  <3B3417F9.2BC0CA3A@mindspring.com>
References:  <Pine.LNX.4.20.0106222258500.12615-100000@www.everquick.net>

next in thread | previous in thread | raw e-mail | index | archive | help
"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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B3417F9.2BC0CA3A>