Path: utzoo!attcan!uunet!snorkelwacker!usc!rutgers!mephisto!bbn.com!lkaplan From: lkaplan@bbn.com (Larry Kaplan) Newsgroups: comp.arch Subject: Re: fork and preallocation (was Re: Paging page tables) Message-ID: <58330@bbn.BBN.COM> Date: 20 Jul 90 14:55:07 GMT Sender: news@bbn.com Reply-To: lkaplan@BBN.COM (Larry Kaplan) Followup-To: comp.arch Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 86 I wrote: >>Our kernel (and others, I am sure) allows sufficiently privileged users >>(like root) to ask that some of their memory be wired (not paged). This >>facility could certainly be used for this daemon. I did say this in the >>original posting but some may have overlooked this. mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >Perhaps, your kernel (but not all UNIX, I am SURE) may be able to >do so. But, it has nothing to do with the problem. Can your kernel >allows to force yet unallocated pages to be copied into swap space >and make it wired? Why does this have nothing to do with the problem? We were discussing methods for handling swap space exhaustion without pre-allocation. The ability to wire memory is a very valid aid to solving the problem. When you wire pages on a non-preallocating system, there is no reason to copy them into the swap area. They will never go there. >>If you were to use vfork when forking >>onto another processor, the child would be executing out of remote memory. >>While caches help alleviate the performance penalty, making things local >>is a much better idea. >You misunderstand semantics of vfork. When you want simple, general >purpose fork (including COW fork), it is often (but not always) >reasonable to use other processors for child process. >But, if you are vforking, the parent process is suspended until >child process dose exit or exec. >So, there is no reason to run the child process on another processor. >You should, instead, arrange exec, to be done on other processor. This is an interesting idea, and actually might make vfork useful for us. However, I am unsure that the performance gained by maintaining the vfork hack and creating a new "exec on processor n" syscall would be worth the effort. With COW "fork on processor n" and regular exec, we probably get very close to the same performance and have a syscall that is useful for other things like parallel processing. I think at this point we have alternative solutions that each have benefits but, of course, the time and utility of implementing each needs to be weighed. >>To make vfork set up >>local text anyway would eliminate most of performance advantage it had. >>Note that even for forks onto the same processor, the text segment >>manipulations aren't that expensive >Though, it has nothing to do with the main-stream discussion, you >should learn more about the history of UNIX. Text segment copying >is never a reason for vfork. Vfork was introduced because copying >of large data/stack segment was time-consuming. Sharing of read-only >text segment has very old history. I think you misunderstood this one. I know what vfork was intended for. Our system has other requirements though. Certainly text segment copying is not a reason for vfork. But in a NUMA multiprocessor, vfork (or fork) to another node is a reason for text segment copying. Though no copy is really made except for the pages that are referenced on that node. The same is true for data and stack when going to another node. However, here, copy on reference (or write) can be used. Actually you could say that the way the text segment is brought over is also copy on reference. I think it is apparent that vfork to another node in a NUMA multiprocessor changes the semantics of the call enough to make it inappropriate. vfork to the same node would be fine, but then how do you get any UNIX jobs (lots of serial processes like compiles) running on other nodes. The "exec on processor n" would work but is limited to this use only. COW fork() and regular exec, on the other hand, do pretty well at this job and COW fork is very useful for real parallel programming. >>Part of the point was that Mach is willing to page to all the disks whether >>they are true swap partitions or regular UNIX filesystems. So the ratio >>is very relevant to Mach based systems. >But, if you think you have free disk space, you should have allocated >it for swapping in advance. Why? Then it wouldn't be available for users. The name of the game here is flexibility. Why constrain swap space or user disk space when you can just allow both to allocate from the same place. If you are worried about runaway user disk consumption, thats what quotas are for. #include _______________________________________________________________________________ ____ \ / ____ Laurence S. Kaplan | \ 0 / | BBN Advanced Computers lkaplan@bbn.com \____|||____/ 10 Fawcett St. (617) 873-2431 /__/ | \__\ Cambridge, MA 02238