Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!mvb.saic.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: 3 Mar 1994 04:29:52 GMT Organization: Weber State University, Ogden, UT Lines: 68 Message-ID: <2l3p40$hdi@u.cc.utah.edu> References: <RA0Jn4G.dysonj@delphi.com> <2kudpoINNbhd@CS.UTK.EDU> <1994Mar1.132637.58107@ans.net> NNTP-Posting-Host: cs.weber.edu In article <1994Mar1.132637.58107@ans.net> dennis@ans.net (Dennis Ferguson) writes: >I don't think it is quite so easy, or clear. Pages are explicitly >allocated by sbrk(), but are also implicitly and tentatively allocated >by fork(). If a 60 Mb process wants to fork() so it can execve() a small >shell command, do you really want to have to configure an extra 60 Mb >or more of swap space to allow this, or make the fork() fail if the >backing store for the entire extra 60 Mb isn't available? With >copy-on-write fork()s a fork()-exec() is extremely likely to actually >use nearly none of that allocation, and I think you get a more useable >system if you don't demand that it be there. Actually, this was the origina intent behind vfork() -- to avoid the copy. But the primary need to copy can be either delayed or totally avoided simply by noting that one need not duplicate read-only pages, which should mean all text pages and some data pages (assuming the use of "const" or the lack of "-fwriteable-strings" on the cc line). The actual copy area is rather small. A process can need more pages than it expects to need either by copy on write of a data page at copy time, mmapping of files into the process address space (and subsequent modification) or on a stack grow. The only method that would serve to protect those cases the majority of the time is to either disallow the abilities granted by the newer architectural features, or to keep a small (10%) memory overdraft area, in the same way the FS does for hashed block allocation. I am loathe to emply this second approach, sine it implies real memory is less than total swap, which I dislike. The primary issues I would like to see addressed are the pollution of user space with ETXTBSY errors from system calls, when even now it would be possible to fault the image to swap and allow the operation as if an problem had not occurred by the inclusion of a simple additional bit definition, and the death of processes over NFS (or other remote FS) when their backing store is overwritten by forcing the copy of the image to swap if the image originates on a remote FS -- note the word "originates", since unless this is strictly enforces, a loopback FS could easily make a remote file SEEM to be a local file when it was not. Of course, this could be a "feature", but I would prefer such a "feature" be implmented as a mount option on the NFS itself instead. The copy to local swap will do little to allow the true "diskless" clients to continue to operate on server death (assuming swap is on the same server that the images are mounted from) but it will make VFS swap faster for existing images by doing swap I/O instead of proxy vnode I/O, and "dataless" clients (machines with local swap but not local disk otherwise, or local disk not used for OS installation) would continue to operate through a server crash/restart without interruption. Those of you familiar with Sun's "dataless" installations will note this as an improvement over the "machine hangs until the server comes back up" operations typical of such Sun machines. I am particularly interested in "dataless" machines, because there is not any reason that a "dataless" machine could not have a swap file *anywhere* -- including on a DOS partition, or it could even use the Windows swap area if one were allocated and Windows didn't use it for state information. Using the "boot.com" program by Martin Renters, this would let you conver a DOS machine into a relatively high performance BSD machine -- and back -- at will... a good configuration for a student lab for an equipment-poor CS department. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.