Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: UNIX Facilities for Interpreters
Message-ID: <7085@mimsy.UUCP>
Date: Tue, 16-Jun-87 22:41:16 EDT
Article-I.D.: mimsy.7085
Posted: Tue Jun 16 22:41:16 1987
Date-Received: Thu, 18-Jun-87 04:38:01 EDT
References: <540@iscuva.UUCP> <8300006@iaoobelix.UUCP> <680@nu3b2.UUCP> <21204@sun.uucp>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

>>WHAT is the benifit over an approprately set quantity of disk-block buffers?

In article <21204@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>3) You don't tie up parts of your buffer cache for long periods of
>time while the pages are in your address space after a "vread".
>(Note also that there may be systems where there *is* no conventional
>buffer cache *per se* ....)

And indeed, the new VM system under development for SunOS (and
eventually 4BSD) does away with the buffer cache, as have other
experimental Unix kernels.  The old PDP11 kernels did not have core
maps, and buffer caches were sensible; but more real memory means
that you should do something useful with it, which requires something
like a core map.  There is no good reason to have both a core map
(which remembers which pages of memory came from where on what
disks) and a buffer cache (which remembers which pages of memory
came from where on what disks).

	for (i = 0; i < count; i += CLBYTES / DEV_BSIZE)
		if (mfind(dev, bn + i))
			munhash(dev, bn + i);
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris