Xref: utzoo comp.arch:11093 comp.sys.mips:106
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!blake!lgy
From: lgy@blake.acs.washington.edu (Laurence Yaffe)
Newsgroups: comp.arch,comp.sys.mips
Subject: Re: Memory utilization & inter-process contention
Message-ID: <3357@blake.acs.washington.edu>
Date: 23 Aug 89 20:44:08 GMT
References: <3332@blake.acs.washington.edu> <2394@unisoft.UUCP>
Reply-To: lgy@newton.phys.washington.edu (Laurence Yaffe)
Organization: University of Washington, Seattle
Lines: 77

In article <2394@unisoft.UUCP> cander@unisoft.UUCP (Charles Anderson) writes:
-From article <3332@blake.acs.washington.edu>, by lgy@newton.phys.washington.edu (Laurence Yaffe):
-> 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, ... ?
-
-Straight out of school  I worked on a proprietary, non-Unix system that
-handled this problem fairly well (even though the company went out of
-business).  In addition the usual queues for runable procs, I/O waiting
-procs, etc, the operating system had a "trouble maker" queue.  This was
-for processes that were making too many demands on the system, i.e.
-encouraging thrashing.  Processes on the TM queue were stripped of
-their resources (essentially swapped out, I think).  After a while they
-were allowed to return and were given some extra grace because the
-first thing they're going to do is page-fault in their working set
-which would otherwise land them right back in the pokey.
-
-In the example that Mr. Yaffe gives, there would be two processes, A &
-B, competing with one another and thus driving the system towards
-thrashing.  The system sees this, selects A as the trouble maker and
-puts him in the penalty box.  B runs fine without A getting in his
-way.  After a while A is allowed to return and he starts slamming
-against B.  A is graced, having just returned from the TM queue, so B
-gets selected for the TM queue and A runs well until B returns when the
-sequence repeats again.  I don't know how well this would work on a real 
-Unix system, but it seemed to work well for this particular system.  
-
--- 
-Charles.

    Of the various responses to my initial query, this note by Charles
Anderson comes closest to the sort of approach I've been wishing for.
It has the virtues of:

a) being dynamic - responding to what a process actually does, not what
   some user said it might do.  This is clearly desirable.  I take it
   for granted that static, rigidly enforced job queues ala IBM are a
   prime case of the "cure" being as bad as the "disease".
   ("I'm sorry, your job ran for 2 weeks before exceeding the page fault
   limit you initially guessed.  You lose.  Try running it again with a
   larger limit...")

b) approximating what a human system manager typically does:

	notice that the system is starting to thrash, 

	look at the active processes and see which ones
	are generating high page fault rates,

	find out the effective "working set" size of these processes
	and figure out which processes can effectively run concurrently,

	try putting one or more of the processes "on hold"
	in order to allow the remaining processes to run effectively,

	periodically reevaluate the situation and readjust which (if any)
	processes should be put "on hold".

    Whether "on hold" means explicitly swapped out, or suspended, or
    simply restricted to a small, but non-zero number of physical memory
    pages is an implementation issue (about which I was hoping to hear
    some interesting discussion).  I do know that simply manipulating
    "nice" values is not adequate (at least on the systems I use) for
    preventing memory contention.  I don't know the "best" way to
    implement this sort of approach - I'm a full time user and part
    time system manager, not an OS guru.

The important point is the need for some sort of intelligently selected,
dynamic response which prevents system resources from being allocated
excessively "democratically" at times when "equal shares for all"
turns into "everyone starves".

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