Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!uunet!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: 386 Memory Management
Message-ID: <611@philica.ica.philips.nl>
Date: 1 Jun 90 06:21:10 GMT
Article-I.D.: philica.611
Reply-To: adrie@.ica.philips.nl ()
Organization: Philips TDS, Innovation Centre Aachen
Lines: 30

To all 32-bit 386 implementors,

I don't know whether there's only one 32-bit 386 Minix implementation
under development (Bruce), or maybe other guys are trying as well to
get Minix running in 32-bit mode? What I would like to know is how
they organize the available physical memory and how they allocate it
to processes. The Memory Manager decides the strategy to allocate
physical memory and it allocates it in continuous pieces to processes.

I'm working on a Minix port to a Sparc computer and assign each process
a continuous piece of physical memory and map it at virtual address 0.
That way, each process start at address 0. That way, the MM need not be
changed and memory allocation is fairly easy. The only disadvantage is
the amount of memory, allocated to a process, cannot be changed when the
process runs. Not on stack-faults nor BRK system calls. I still have to
use the `chmem' program and decide by try and error what the initial gap
should be (I had to increase the gap for the GNU C-compiler to 700000
and the assembler to 500000 to be able to compile big programs).

The best method would be to change the MM to divide the physical memory
in pages of 4KBytes (most paging MMU's, including the SparcStation's MMU
and the I386, use 4K pages), and deliver physical memory to the processes
as they need it.

So how did the 386-guys implement it? Do they use paging and/or
segmenting? Is Andy willing to change the MM to adapt to paging MMU's?

Adrie Koolen,
Philips Innovation Centre Aachen, (West-)Germany
e-mail: adrie@ica.philips.nl