Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: fork and preallocation (was Re: Paging page tables)
Message-ID: <5908@titcce.cc.titech.ac.jp>
Date: 20 Jul 90 04:16:37 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5DL4SPD@xds13.ferranti.com> <5855@titcce.cc.titech.ac.jp> <58184@bbn.BBN.COM> <5870@titcce.cc.titech.ac.jp> <58227@bbn.BBN.COM> <5894@titcce.cc.titech.ac.jp> <58307@bbn.BBN.COM>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 101

In article <58307@bbn.BBN.COM> lkaplan@BBN.COM (Larry Kaplan) writes:

>Anyway, I'll address some unclear points and provide a little more 
>justification than I have before.

OK, now, at last, you present a justification.

Now, debate on COW fork vs. vfork can begin. But, be sure that, vfork
is only useful just before exec.

Let me show that your justification is wrong.

>>Oops! A program? Are you joking? What if the program itself run short
>>of pages?

>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.

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?

>>I showed several justification why simple fork is not appropriate
>>for fork-exec.
>
>But the debate is COW fork vs vfork.

Simple fork, I mean, includes COW fork.

>>Have you shown any justification to claim so? Or, is it merely your
>>desire?

>Let me attack this one now.  Let me start by saying that the problems
>we have with a regular vfork are probably fairly machine specific.  However, 
>some of this reasoning may soon apply to other machines if not already.

I don't think so. But, I don't want to fork the discussion. So, let's focus
on your architecture.

>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.

>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.

>Please, please, please, I said disk space to real memory, not swap space.

Sorry about my misunderstanding.

>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.

>>>Even just reads from parts of the matrix wouldn't require
>>>swap space allocation since the pages aren't dirtied.  This sounds quite
>>>likely.

>>You can do so with mmap specifying readonly option. A cleaver implementation
>>won't allocate extra swap space.

>>BUT, such a thing has nothing to do with fork nor vfork.

>But it does have to do with preallocation and COW fork vs vfork.  Again any
>mmap calls require application code changes that the non-preallocating
>scheme doesn't need.

But, without mmap, how can you set values to the read-only matrix?

It can not be a part of data segment, because your program, practically,
can not have huge number of initializer lines for the large matrix.

I thought, it can only be a file output from another program.

						Masataka Ohta