Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!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: <5928@titcce.cc.titech.ac.jp>
Date: 23 Jul 90 04:29:31 GMT
References: <58330@bbn.BBN.COM>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 87

In article <58330@bbn.BBN.COM>
	lkaplan@BBN.COM (Larry Kaplan) 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?

Because, you can't wire a yet-unallocated page.

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

Wiring is not essential. It is only necessary to actually allocate
space.

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

Again, if a page is not allocated, there is nothing to wire.

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

You were worrying about copying effort of text segment very much,
weren't you?

If you always exec on other processor, the text segment of the original
processor is untouched, and maybe, used later, without accessing
global momory.

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

Nothing is apparent to me.

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

"exec on processor n"? Why can't a regular exec performed on some
other appropriate processor? Is a process id tied to a processor?

If you have a apprication on current UNIX which uses lots of parallel
processes with vfork and exec, you can run it on multi-processor
with full parallelism without changing the code.

>COW fork() and regular exec, on the other hand, do pretty well at this job 

As for the COW-fork performance, which I am not interested in so much,
someone said some workaround (pre-copying of several pages) is necessary
to gain suffecient speed.

As for the pre-allocation problem, there only exists complex and
incomplete workaround exists.

>and COW fork is very useful for real parallel programming.

Yes, you may have fork, which may be COW.

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

Flexibility? It is an illusion. Actually, it is only complexity of
management. There is positive correlation for a common process
between amount of file space and amount of swap space.

>If you are worried about 
>runaway user disk consumption, thats what quotas are for.

It is not acceptable for me, but if you don't mind losing of computation
result due to quota, you shouldn't mind pre-allocating COW fork.
Pre-allocating fork is only as bad as disk quota.

						Masstaka Ohta