Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!SDSC.ARPA!GKN
From: GKN@SDSC.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Buffered vs. Direct I/O requests
Message-ID: <8701302307.AA14514@ucbvax.Berkeley.EDU>
Date: Fri, 30-Jan-87 12:36:07 EST
Article-I.D.: ucbvax.8701302307.AA14514
Posted: Fri Jan 30 12:36:07 1987
Date-Received: Sat, 31-Jan-87 08:43:56 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: San Diego Supercomputer Center
Lines: 31
Approved: info-vax@sri-kl.arpa

A buffered I/O request is one where a system buffer, allocated from non-paged
pool, is involved.  The amount of pool required for the system buffer is
charged against your BYTLM quota at the descretion of the device driver.

A direct I/O request is one where the I/O transfer takes place out of the
buffer space you specified in your program.

In order for I/O to take place, the contents of the physical page frames
which contain the I/O buffer must not change while the I/O is going on.
For buffered I/Os this feat is accomplished because the I/O buffer is
allocated from non-paged pool, which doesn't page.  For direct I/O requests
this feat is accomplished by temporarily locking the pages involved in
the I/O transfer into memory and doing the I/O from there.

Direct I/O requests are usually for devices which do I/O quickly, since
locking pages in memory tends to destroy paging dynamics.

The type of request (buffered vs. direct) is at the descretion of the
driver writer when s/he codes the FDT.

gkn
--------------------------------------
Arpa:	GKN@SDSC-SDS.ARPA
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (5.600)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA  92138
AT&T:	619.534.5076
-------