From: utzoo!decvax!harpo!seismo!rlgvax!guy
Newsgroups: net.unix-wizards
Title: Re: Unix buffers thought
Article-I.D.: rlgvax.306
Posted: Wed Apr 20 22:30:35 1983
Received: Fri Apr 22 07:27:34 1983
References: isrnix.197

Another reason to provide a O_NOCACHE bin on open; you could bypass the
caching overhead.  If you were running a big DBMS or a FMS (ISAM, VSAM, etc.),
you'd have your own big buffer pool anyway, so the system buffer pool
might not buy you all that much (see the Stonebraker paper mentioned in an
earlier article); UNIX's caching and read-ahead mechanism won't match what
yours is (Stonebraker mentions a case where INGRES reads a block and KNOWS
what block it is going to want next; unfortunately, UNIX may the next
sequential block from the file instead, or just not read anything ahead);
and your caching will disrupt programs which can make use of the cache.
(It has been mentioned several times that an "exec" rips through the cache
and disrupts it quite a bit, as a lot of the blocks read in will never be
used again.)

BTW, the System III kernel buffers aren't mapped into kernel address space
(except for a few used for things like arg lists, super-blocks, etc.), and
they have a routine which will map the buffer and the source/destination
and use a fast copy loop.  Anybody out there have any comparative figures
on, say, PDP-11 V7 buffer copy overhead vs. PDP-11 S3 buffer copy overhead?
If you're reading one character at a time, the fancy copy routine will lose,
of course; on the other hand, if you're reading one character at a time
ANYTHING will lose.

						Guy Harris
						RLG Corporation
						{seismo,mcnc,we13}!rlgvax!guy