Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: brk's zero-fill behavior on VAXen
Message-ID: <4687@mimsy.UUCP>
Date: Mon, 8-Dec-86 04:22:38 EST
Article-I.D.: mimsy.4687
Posted: Mon Dec  8 04:22:38 1986
Date-Received: Mon, 8-Dec-86 05:39:46 EST
References: <7208@elsie.UUCP> <544@mcgill-vision.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

>In article <7208@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes:
>>Can system performance be improved by avoiding zero filling ... ?
 
In article <544@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse)
writes:
>Probably.  But probably not measurably.  The VAX has a pte type known
>as "zero-fill on demand" which means that the page is created full of
>zeros when it is first referenced.

Not quite.  There are various bits per page stored in a PTE,
including five bits that are unused in invalid pages.  In 4BSD Vax
kernels, two special values may be stored in those bits to mean
`fill on demand from text inode' and `zero fill on demand'.  The
zero fill is done by code in the page fault handler, not by the
hardware.  But it is still quite fast.

The other 30 possible values for that five-bit field were used to
implement `vread' in 4.1 and 4.2.  The vread system call was dropped
from 4.3BSD, removing a major stumbling block that limited the
maximum number of open files per process to 30.  vread, like vfork,
was an implementation hack.  Unlike vfork, vread proved not terribly
useful.  (vfork is still faster than fork, even in systems implementing
copy-on-write forks.  Sigh.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu