Path: utzoo!attcan!uunet!kddlab!titcca!anprda!akira From: akira@atson.asahi-np.co.jp (Akira Takiguchi) Newsgroups: comp.arch Subject: Re: vfork (was Re: Paging page tables) Summary: Vfork is good for `big process cannot fork' problem, but introducing delay-swapspace-allocation process option can be useful. Message-ID: <928@anprda.atson.asahi-np.co.jp> Date: 12 Jul 90 05:55:50 GMT References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <1990Jul11.191235.8117@cs.rochester.edu> <269B8E4F.27941@ics.uci.edu> Reply-To: akira@anprda.atson.asahi-np.co.jp (Akira Takiguchi) Organization: ATSON, Inc. Lines: 26 In article <269B8E4F.27941@ics.uci.edu> baxter@zola.ics.uci.edu (Ira Baxter) writes: >But one can walk a >middle road: allocate the space, but only assign it incrementally when >COW actually happens. Space allocation given a fixed supply is a >simple matter of adjusting a semaphore count. If one wanted to mix >the policies, all you need is a hint to vfork (or whatever) that says ^^^^^ never vfork, but fork >"allocate now" or "delay allocation". This scheme works fine for `big process cannot fork'-problem, but you cannot get rid of for-years-existing vfork() only for that reason, since introducing a new argument to fork() cannot be considered a good idea. I'm not saying your scheme is useless; there is another motivation to introduce delayed swapspace-allocation option. If you want a huge array to be used very sparsely but you cannot afford sufficient swap space, this idea can be useful [I can't think of such an application now, but there could be one]. This time you don't need a new argument for fork() - but a new call, something like swapadvise() will do. If you know you are going to allocate huge space and you may risk the process to be killed by the OS, you can make this call upon program startup. -- Akira Takiguchi @ ATSON, Inc.