Xref: utzoo comp.arch:11064 comp.sys.mips:89
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!indri!caesar!blake!lgy
From: lgy@blake.acs.washington.edu (Laurence Yaffe)
Newsgroups: comp.arch,comp.sys.mips
Subject: Memory utilization & inter-process contention
Keywords: paging, swapping, scheduling
Message-ID: <3332@blake.acs.washington.edu>
Date: 22 Aug 89 05:53:58 GMT
Reply-To: lgy@newton.phys.washington.edu (Laurence Yaffe)
Organization: University of Washington, Seattle
Lines: 45


     After all the talk in comp.arch about cache and memory system design
at the hardware level, how about some discussion on higher level issues
relating to memory utilization, process scheduling, or resource contention?

    A lot of current machines, such as my MIPS box, have pretty standard
virtual memory systems: demand paging is used to allocate real memory to
individual processes, with some sort of least-recently-used algorithm
employed to select pages to write out (or forget) when virtual memory use
exceeds real memory.  This seems to work reasonably well if your typical
job mix consists of numerous small processes.  But severe, and unnecessary,
performance degradation can occur if you have several processes which have
very poor locality of reference when accessing their data, are sufficiently
small that any singly process can fit in real memory, and yet sufficiently
large that no two processes will fit in real memory.

    As a concrete example (typical of what I've been trying to run lately),
suppose you have a 32 Mbyte system and that there are only two processes
running, each of which uses 25 Mbytes of virtual memory (almost all data space)
with rapid, random access patterns.  (I.e., normal behavior for a program like
Mathematica.)  If only one job were present, it would fit in real memory and
the machine would run at virtually 100% cpu utilization.  With two such jobs
in a demand-paged environment what appears to happen is that each process
typically gets enough real memory so that it denies the other process 
sufficient memory to run effectively - i.e., both processes continually
page fault and cpu utilization plumments.

    This sort of contention could obviously be prevented by a smarter
scheduling technique - something which would entirely swap out one
process for a period of time in order to let the other process run.

Questions:

    Which (if any) high-performance Unix systems are capable of avoiding
this type of inter-process contention?  What works best - actual process
swapping layered on top of demand paging, better paging algorithms,
clever scheduling based on adaptive process priorities, ... ?

    How common is this type of problem?  Anyone else share my feeling that
many Unix systems could do a lot better at handling large processes?
Anyone else share my feeling that this is important (and sadly neglected)?

-- 
Laurence G. Yaffe		Internet: lgy@newton.phys.washington.edu
University of Washington	  Bitnet: yaffe@uwaphast.bitnet