Xref: utzoo comp.arch:11083 comp.sys.mips:102
Path: utzoo!yunexus!davecb
From: davecb@yunexus.UUCP (David Collier-Brown)
Newsgroups: comp.arch,comp.sys.mips
Subject: Memory utilization & inter-process contention
Message-ID: <3344@yunexus.UUCP>
Date: 23 Aug 89 12:22:37 GMT
Article-I.D.: yunexus.3344
References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp> <26642@shemp.CS.UCLA.EDU> <3345@blake.acs.washington.edu>
Organization: York U. Computing Services
Lines: 34

[In a discussion of excessive inter-process memory contention ]
lgy@blake.acs.washington.edu (Laurence Yaffe) writes:
| I'd like to emphasize that it should be rather easy for an OS to recognize
| when excessive page faulting is causing the system to thrash.
| And once that happens, there's plenty of unused cpu cycles which could
| be used by the OS in order to decide what to do about it!  So adding
| some intelligence to the OS to better cope with this type of problem
| need not have significant negative impact on ordinary interactive behavior.

	The execution of this policy should be fairly cheap: deciding on
when to carry it out might be harder.
	I'll argue that a daemon which detects processes thrashing the
system can find all the processes which should be scheduled sequentially,
but will have to do a large amount of work ensuring that they're really
non-interactive, able to be arbitrarily delayed, etc.  Once you do the
decision making, the kernel can smash their priorities down "below the
flashing lights", or make them the idle process itself.

	I really wouldn't care to have the policy-maker in a kernel.
I think the risc/cisc complexity/cost arguments apply here (and that's
the only thing about architecture in this whole posting).

	For practical purposes, the SysV printer spooling system is really
quite a general-purpose creature, and can be turned into a mechanism for
simulating a batch queue (source: Drew Sullivan, personal communication).
	As we have a machine (Mips M2000) with such a spooler sitting there
unused, I'll have to see about using it as a batch queue for our scientists'
number-crunching jobs.
					--dave
-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 223-8968      |    He's so smart he's dumb.