adrie@philica.ica.philips.nl (Adrie Koolen) (06/01/90)
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
mcm@redwood.ucsb.edu (Marcelo C. Mourier) (06/02/90)
In article <611@philica.ica.philips.nl> adrie@.ica.philips.nl () writes: > >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 I'm working on a 32-bit kernel for Minix on the i386 that's going to use the paging mechanism of the CPU to implement virtual memory. As a consequence I made some substantial changes to the way the virtual address space of a pro- cess is laid out, and the way memory management is done. Actually, I'm con- sidering moving all the MM code to the system task in the kernel, instead of having it as a separate server process. This way, a lot of overhead would be eliminated between the kernel and the MM process, which is necessary be- cause now we have to deal with page-faults! The approach I'm taking completely skips the segmentation mechanism of the i386, all segments are based at linear address zero, and are 4G-long. This way the virtual address space == linear address space, and all the remaping is done by the paging mechanism. I'm using SCO's Unix V/386 as the developement system and I still have a long way to go. I'm using Minix 1.5 as a reference. If there's anyone interested I could periodically post or mail the progress/retrocess I make... Marcelo - mcm@cs.ucsb.edu
brucee@runxtsa.runx.oz.au (Bruce Evans) (06/04/90)
(Please send any reply to this to my other address, evans@ditsyda.oz.) In article <611@philica.ica.philips.nl> adrie@.ica.philips.nl () writes: >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 The only implementation independent of mine that I know about is by a group with ari@hut.fi. Some people are attempting to cross-compile my stuff. I can build it native using gnu tools. >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's about all I'm doing. The mapping is done with segments as in 1.5.10 (zero changes to MM). It runs in paged mode, but only to map some RAM below 640K to make all (non-kernel) RAM is contiguous (so gcc fits :-). >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). Same :-(. Recompiling gcc requires chmem =1150000. I only have 2M and with gcc that big, make no longer fits. Bruce Culbertson implemented paging for Minix on a 32K. It has complications like a 512 byte h/w page size and a 1K s/w page size. I have been meaning to use some of the code for that for almost a year but have been doing too much busywork for 1.5.x.