Path: utzoo!attcan!uunet!lll-winken!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Message-ID: <5813@titcce.cc.titech.ac.jp>
Date: 9 Jul 90 11:33:02 GMT
References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> <PCG.90Jun30230310@odin.cs.aber.ac.uk> <58001@bbn.BBN.COM> <5796@titcce.cc.titech.ac.jp> <1990Jul6.160004.896@zoo.toronto.edu>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 68

In article <1990Jul6.160004.896@zoo.toronto.edu>
	henry@zoo.toronto.edu (Henry Spencer) writes:

>In article <5796@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>>If a large process want to fork(), it requires a large amount of virtual
>>memory space (twice the size of the process). So, if the process almost
>>used up virtual memory space, the process can not fork(). Copy-on-write
>>won't help.

>Nonsense.  There need not be any concept of "using up virtual memory space".
>Virtual memory is *virtual*;

Sigh..., It seems to me that I must explain AGAIN in this newsgroup
why vfork() is essential.

Virtual memory is NOT nothing.

>only when those pages need to become real do
>they consume resources.

OK. You are correct here, though the terminology is confusing (real hear
dose not means you need real memory, but means you need swap space).

So, perhaps, you know when a page need to be allocated
swap space. With copy-on-write scheme, a page need swap space
when the page is written something.

>Forking large processes without needing lots more
>memory/disk just requires an intelligent implementation.  Unfortunately,
>intelligent implementors are scarce.

I admit that that is an elaborated implementation. But, in general,
elabolation should be considered vice in UNIX.

In this case, the INTELLIGENT implementation is much worse than a
simple-minded (tough copy-on-write is already too much elaborated,
and thus vice) implementation. Fortunately, INTELLIGENT implementors
are scarce.

If you think virtual memory is free and allow forking without reserving
actual swap space, when  swap space is required, it is often the case
that, there is no free swap space, anymore.

That is, if a process (which may not be a large process, it may even
be a system process) write to a copy-on-write page, it can't. The situation
is deadlock and to resolve it, some process must be killed.

In some INTELLIGENT implementation, swap space for read only text
page will also be allocated on request, so, even instruction read
(not write) will cause deadlocking.

The problem is serious when you do a large scale computation.

>Vfork is an abomination invented by lazy people; the sooner it goes,
>the better.

You should understand laziness is virtue in UNIX.

>(Please don't tell me that hardware problems prevented them
>from implementing copy-on-write; copy-on-access they *could* have done,
>and it would have been almost as good.)

But, the reason why vfork survives in 4.4BSD is, as I heard from
a person in Berkeley, that vfork is faster than fork. Even with
an elabolated shared memory mechanism of 4.4BSD, it takes time
to spawn a large completely new process.

						Masataka Ohta