Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!decwrl!decwrl!csus.edu!netcom.com!hasty From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: Disk Thrashing question Message-ID: <hastyCE371K.Eu2@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <288mln$f82@pdq.coe.montana.edu> <hastyCE206B.4ys@netcom.com> <CE2spD.1pp3@ns1.nodak.edu> Date: Tue, 28 Sep 1993 23:10:31 GMT Lines: 54 In article <CE2spD.1pp3@ns1.nodak.edu> tinguely@plains.NoDak.edu (Mark Tinguely) writes: >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. Add a trap to signal this condition, and you may have a nice system at your hands. Cheers, Amancio -- This message brought to you by the letters X and S and the number 3 Amancio Hasty | Home: (415) 495-3046 | ftp-site depository of all my work: e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/incoming