Path: utzoo!mnetor!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!f.gp.cs.cmu.edu!mwyoung
From: mwyoung@f.gp.cs.cmu.edu (Michael Young)
Newsgroups: comp.arch
Subject: Re: ZFOD before COW
Message-ID: <1601@pt.cs.cmu.edu>
Date: 4 May 88 21:48:09 GMT
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 45

The original Mach implementation of zero-fill-on-demand memory
worked exactly as "aglew@gould.com" asked.  One "zero fill" memory
object, containing one zero-filled page, was used to back all
read-only requests.  Two performance issues lead us to change:

	Very few zero-fill pages are read but not written.  The
	extra memory fault (to copy-on-write a zero-fill page)
	cost too much for almost all applications.  [Furthermore,
	the page was copied from the original zero-fill page
	(just like any other copy-on-write operation), rather
	than zero-filling.  This added cost could be optimized
	away, but we didn't.]

	Many architectures make sharing a single physical page
	at several virtual addresses undesirable.  For example,
	the IBM RT/PC only allows page sharing at the segment level.
	To use one physical page would cause a fault on each
	new virtual address.

So, each zero-fill fault gets a fresh page.  However, these pages
are not "dirty" and are easily reclaimed during pageout; no backing
storage is wasted.  Still, the cost of zero-filling at all is high.

Several simple changes to Mach could be made to accomodate this
application:

	Mark zero-fill pages as such until they're dirtied, and possibly
	keep them on a separate free page list.  This makes it unlikely
	that it's necessary to zero-fill a new page.  This may be all you
	can do on an architecture with the virtual address aliaising problem.

	Restore the old "zero fill object", and use it if the architecture
	allows.  This involves hackery in the fault handler to reduce
	all pages in that object to the single "zero fill page".

	Manage a "user-defined" zero-fill object using the Mach external
	memory management interface.  If built into the kernel, the manager
	could cheat to use the same physical page for all virtual addresses.
	[This cheating is similar in form to how drivers for memory-mapped
	devices fit into the Mach VM system.]

For information on obtaining Mach sources, send mail to "mach@wb1.cs.cmu.edu".
Technical comments or questions can be directed to "info-mach@wb1.cs.cmu.edu".

			Michael