Xref: utzoo comp.arch:11074 comp.sys.mips:96 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!ogccse!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: <3345@blake.acs.washington.edu> Date: 22 Aug 89 23:48:04 GMT References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp> <26642@shemp.CS.UCLA.EDU> Reply-To: lgy@blake.acs.washington.edu (Laurence Yaffe) Organization: University of Washington, Seattle Lines: 36 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