Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!haven!decuac!pa.dec.com!news.crl.dec.com!decvax.dec.com!crater!paradis
From: paradis@crater.zk3.dec.com (Jim Paradis)
Newsgroups: comp.os.minix
Subject: Re: Help needed with MINIX scheduler
Message-ID: <460@decvax.decvax.dec.com.UUCP>
Date: 30 Nov 90 00:33:43 GMT
References: <37646@nigel.ee.udel.edu>
Sender: news@decvax.dec.com.UUCP
Reply-To: paradis@crater.UUCP (Jim Paradis)
Organization: DEC ULTRIX, Nashua, NH
Lines: 34

In article <37646@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes:
>So, stack&data must share the ADDRESS SPACE, but, they can be separated
>by a big gap, allowing each range to grow.

Ah yes... this has been pointed out to me several times in e-mail as well
Anybody got a towel so I can wipe the egg off my face? 8-).

Believe it or not, I hack UNIX kernels for a living, and VM is one of my
specialties... I know all about putting text+data+bss+heap at the bottom
of the address space and putting the stack at the top.  Thing is, most
UNIces allocate a whole flat virtual address space (i.e. 4Gb) for EACH
process, so this is never a problem.  In order to keep my MINIX VM
implementation simple (and to make the fewest changes to MM), I decided
to run the whole system in a SINGLE virtual space.  This makes virtual
address space SOMEWHAT of a scarcer resource (instead of 4Gb/process,
I've got to make all the processes divvy up the 4Gb among themselves).
I suppose I could just give each process, say, 16Mb (max. physical memory
supported by most 386 boxes).  While that limits me to "only" 256
processes per system, that probably won't be TOO much of a limitation
for a 386-box class machine 8-).

(actually, what I planned to do was to have two classes of processes:
big and normal.  A normal process runs like they do today: it's chmem'd
to a certain value, and it gets that much space when it execs.  A big
process is chmem'ed to zero, and when exec detects this is allocates
one of these 16Mb hunks for it instead.  This way, small processes with
well-bounded VM behavior don't need to chew up big amounts of VM space...)

As for why I might consider 16Mb to be a tight virtual address space...
remember: I want to run GCC and Gnu Emacs 8-) 8-) 8-)


Jim Paradis, working at but not employed by DEC.	(603)881-1221
paradis@decvax.dec.com     			"All I got was a rock!"