Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!news.clark.edu!netnews.nwnet.net!ns1.nodak.edu!plains.NoDak.edu!tinguely From: tinguely@plains.NoDak.edu (Mark Tinguely) Subject: Re: Disk Thrashing question Sender: usenet@ns1.nodak.edu (Usenet login) Message-ID: <CE2spD.1pp3@ns1.nodak.edu> Date: Tue, 28 Sep 1993 18:00:49 GMT References: <rich.749200452@isr0004.urh.uiuc.edu> <288mln$f82@pdq.coe.montana.edu> <hastyCE206B.4ys@netcom.com> Nntp-Posting-Host: plains.nodak.edu Organization: North Dakota State University Lines: 39 In article <hastyCE206B.4ys@netcom.com> hasty@netcom.com (Amancio Hasty Jr) writes: >I think that we should have the recourse for just trashing >those user processs which tend to consume system resources. > >In othere words we should have better heuristics for managing >our system resources just implementing shared library libraries >is not going to make the problem go away. true, but it is hard to get the offending process. The lazy allocation of memory pushes the allocation request and even the backstore decisions to be done as late as possible. The process that own the block that gets pushed out to backstore most likely is not the process that is currently running. As I see it: The VM in *BSD needs a real swapout (and the user structure should really be pushed out in real memory depletion). on backstore depletion, either: A process should be killed (I don't like this will appear random because the offending process can't be accurately located and inside the killed process (even if it was the memory hog) can not determine the cause and affect of memory abuse and the fact that it got killed. Someone describe SGI acting something this in memory depletion. or We "reserve" VM via a counter when a process sbrks (obreak in Net 2), grabs more stack, or user area, variable space on forks. If this counter indicates the request would totally use the backstore plus a percentage of the RAM available for VM (known at boot time -- don't use all leave some for program text), then deny the request. In this way, the lazy allocation of the VM is preserved (in general, lazy alloaction is a good thing). This counter method would be a little conservative. --mark.