Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!MathWorks.Com!yeshua.marcam.com!charnel!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.development Subject: Re: Notes on the *new* FreeBSD V1.1 VM system Date: 24 Feb 1994 05:12:31 GMT Organization: Weber State University, Ogden, UT Lines: 79 Message-ID: <2khcvv$han@u.cc.utah.edu> References: <CLL9J6.FCF@endicor.com> <2ke3ss$l0d@u.cc.utah.edu> <Ja4p+zR.dysonj@delphi.com> NNTP-Posting-Host: cs.weber.edu In article <Ja4p+zR.dysonj@delphi.com> John Dyson <dysonj@delphi.com> writes: Me>Personally, I think you should be required to rebuild a kernel with Me>"option FAST_AND_LOOSE" if you want overcommit enabled. >We have not met, so this is meant in the best of humor.... >hows about "option TIGHT_AND_STINGY" if you want overcommit disabled :-)). Fine with me -- it'll be the default, of course? 8-) 8-). >Terry, I know that that is an issue that you are interested in, and >you won't hear me shouting you down about it... I have read some of >your messages about it and have found them interesting. The market that >you are talking about is different that what a lot of people running some >versions of *BSD are used to. The main problem I would like to overcome is ETXTBSY; ETXTBSY is simply broken. This could be gotten around by causing a write to swap whenever an ETXTBSY whould normally occur -- that is, when you go to install over top of init or you try to overwrite or update a running image during build; it would be easy to detect this and copy the image to swap at that time, then proceed with the operation as if the ETXTBSY had never happened. A faster approach that would not lose the benefits of a fast start by swapping from the image (this is later paid for by slower subsequent page access -- the vnode pager is slower because of block lookup and indirection) would be to allocate, but delay the copy to swap until a page flush (that would normally write a dirty page to swap OR throw away a clean page), where you would write both dirty and clean pages to swap. Subsequent page fetches will be faster as a result. The main killer bug that ETXTBSY processing resulting from running the program using the program image as a swap store is NFS. If I'm running the program off an NFS server, and the server's copy of the image is attempted to be written over from the server, there is no flagging of the vnode on the server that it is being used to execute an image; this is inherently insoluable because of NFS' statelessness making it totally impossible to flag the server image. Since it isn't flagged, it might even be another client machine that causes the change in the file and screws up the image for the first client. It's my opinion that one user should not be able to crash another users prgram instance without either having the same credentials or having superuser credentials, and even then, they should have to use "kill". The ONLY possible alternative that will keep the image running on the client machine is to copy the image to local swap if the image is being read from a remotely mounted FS. The other reasons for skipping overcommit are: 1) Avoid the gratuitous kill off of your process. This would require preallocation of swap, and would only save you in the copy-on-write case -- you could still die from a stack grow. This could be handled in the majority of cases by keeping a percentage in reserve for use ONLY by existing processes. 2) With enough swap as memory backing store: a) Real panic dumps with full info for a post-mortem. b) "Instant on" in the form of restoration of a previous system state. c) Successful power managment on laptops. Other arguments could be made for images from file systems mounted from disk controllers on PCMCIA cards (that could be removed without notice), and similar circumstances. I have been thinking on this a long time, and I get a little religious... 8-) 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.