V.3 + top

[David F. Carlson]

In article <10770005 at hpcupt1.HP.COM>, vandys at hpcupt1.HP.COM (Andrew Valencia(Seattle)) writes:
> comp.unix.microport / fox at 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.
> 
> 	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.

It is my impression (and I may be wrong about modern UNIXes) that the u part
of a process is distinct from the proc part of a process *solely* so that
the u part may be swapped out when not running but that the proc part is
never swapped so that scheduling is not produce a swapping deadlock.  This
swapping (or really effectively paging) was very important for V7 on PDP11
or any other 16 bit address space machine.  My knowledge of source for the
286 port in limited but the separation of u from proc was/is a critical
OS design decision.

fodder
fodder
fodder
fodder
fodder
fodder
-- 
David F. Carlson, Micropen, Inc.
micropen!dave at ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll