Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!ucbvax!hplabs!hpda!hpcupt1!vandys
From: vandys@hpcupt1.HP.COM (Andrew Valencia(Seattle))
Newsgroups: comp.unix.microport
Subject: Re: V.3 + top
Message-ID: <10770005@hpcupt1.HP.COM>
Date: 20 Oct 88 17:18:38 GMT
References: <468@alice.marlow.uucp>
Organization: Hewlett Packard, Cupertino
Lines: 44

/ hpcupt1:comp.unix.microport / fox@marlow.uucp (Paul Fox) /  3:30 pm  Oct 12, 1988 /
>OK, so in my system I have a proc limit of 100 processes. It seems
>to me that the u area for these 100 procs pretty much resides in
>physical memory all the time. Net result: 100 * 8K taken up in
>'u' areas. Thats 800K. Add this to the 500K disk buffers + 1MB for
>the kernel. We end up with 2.3MB used up. That leaves me with 1.7MB
>for my processes before we subtract the other bits needed by my kernel.

	I'm doing the port of V.2 regions to our 680x0 line of processors,
and have had some experience with this stuff at this point :->.  Although
my comments really only apply to the code I'm porting (which is actually
a port of V.2 to our RISC line), some of it probably applies.

	A region represents the actual set of pages representing the object.
Not all of the pages need be present.  A pregion supplies a view onto the
region.  Thus, for memory-mapped files, a region would represent the whole
file, whereas a pregion might give a window of only the first couple pages.
We use this to exec a.outs--a text region simply views the text image portion
of the a.out file.

	For the U area, we actually allocate 3 pages--one for the U area,
one for the kernel stack, and one for the kernel red zone.  The red zone
doesn't really have a page, and traps the kernel if it over-grows its stack.
While a user is running, there are actually two pregions for the U area--one
which maps it in kernel virtual address space, and another to map it into
the user's address space.  This latter is done mostly for compatibility,
although some supporting code for signals (the "signal trampoline" code) is
also located there.

	Our pageout daemon (actually known as "vhand") executes a typical
"scan and age" algorithm.  It works its way through the the regions of a
user's virtual address space (which actually hang off a "vas" structure),
arranging for some pages to be freed (if they are old and unmodified) or
written out (if they are old and modified).  The U area pregions hang off
the vas, and thus--you guessed it--can be paged out.  When the process later
runs, the pages are brought back in and execution continues.

	The performance problems we had with regions didn't have much to
do with simple memory usage.  We found some of their locking techniques
naive and wasteful.  We also found some bugs with how they managed pages
over time.  On the other hand, with some cleanup we have found the code
to be much more suitable for techniques like mapped files, shared libraries,
and other fancy VM features than, say, the 4.2 VM code.

				Andy