🚀 go-pugleaf

    In article <26642@shemp.CS.UCLA.EDU> frazier@cs.ucla.edu (Greg Frazier) writes:
    >In article <1989Aug22.163100.25540@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
    >=>In article <3332@blake.acs.washington.edu> lgy@newton.phys.washington.edu (Laurence Yaffe) writes:
    >=>>	[ comments about excessive inter-process memory contention ]
    >=>
    >=   [ comments about avoiding thw whole situation ]
    >
    >The original posting was asking if there was an OS smart enough
    >to run the jobs in sequence for him.  That's the point - most
    >machines experience a wide range of workloads, and cannot be
    >customized for each one of them.  Any heavily-used scientific
    >machine is going to experience the described situation at some
    >point in its career.  Now, obviously, if you have somebody

Absolutely correct.

    >monitoring the machine's performance, he can "manually" prevent
    >the two jobs from running simultaneously.  What would be more
    >desireable, however, is for the OS to realize what is going on,
    >and for _it_ to cause the jobs to run sequentially.  I suspect
    >that this would require too much intelligence on the part of the
    >OS, but then, what do I know - I'm just an architect! :-)
    >
    >Greg Frazier

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.

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