Path: utzoo!attcan!uunet!samsung!usc!ucsd!orion.oac.uci.edu!ucivax!baxter
From: baxter@zola.ics.uci.edu (Ira Baxter)
Newsgroups: comp.arch
Subject: Re: vfork (was Re: Paging page tables)
Message-ID: <269B8E4F.27941@ics.uci.edu>
Date: 11 Jul 90 20:38:39 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <1990Jul11.191235.8117@cs.rochester.edu>
Lines: 32

>In <5830@titcce.cc.titech.ac.jp>,
>mohta@necom830.cc.titech.ac.jp (Masataka Ohta) wrote:
>| In article <920@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes:
>| >>With copy-on-write scheme, a page need swap space
>| >>when the page is written something.
>|
>| >But not until.  Page and swap file space allocation is as postponeable
>| >as the memory copy.
>|
>| NO.

I don't understand the problem here.  It appears that objections to
the MVS scheme stem from the notion that one must both allocate AND
ASSIGN the swap space when the potential space requirements appear
(i.e., COW + new virtual space --> allocate and assign swap space for
entire new virtual space because it might be entirely COW'd over
time), at potentially high costs to actually effect the assignment
(find the available swap space, build tables, etc.).  The
UNIX-wait-till-I-need-it scheme suffers from the potential of deadlock
over swap requirements when they finally appear.  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
"allocate now" or "delay allocation".  Then programmers can pick their
poison depending on application requirements; system processes can be
run atomically with respect to their space requirements.



--
Ira Baxter