swap space
Alex S. Crain
alex at umbc4.umbc.edu
Sat Jun 22 01:19:26 AEST 1991
In article <384 at kyzyl.mi.org> tkacik at kyzyl.mi.org (Tom Tkacik) writes:
[This is the pertinant magic describing the process environment]
>#define VUSER_START 0x80000 /* start address of user process */
>#define VUSER_END 0x300000 /* end address of user process */
>#define SHLIB_START VUSER_END /* start address of shared lib */
>#define SHLIB_END 0x380000 /* end address of shared lib */
>#define KVMEM_VBASE SHLIB_END /* start addr of kernel vm */
>#define KVMEM_VLIMIT 0x400000 /* end addr of kernel vm */
[No the questions, reformatted for clarity]
1] This defines how virtual memory space is used in each process.
Yup.
2] They clearly show that the user process goes from 0x80000 to 0x300000.
Yup
3] This is the 2.5MB. Shared libraries must fit into the 0.5MB
between 0x300000 and 0x380000, while the kernel must fit into the
0.5Mb between 0x380000 and 0x400000 (the very top of virtual memory).
Bzzzzt! wrong. The shared libraries live between 0x300000-0x380000.
The top .5 megs is dynamic memory for the kernel, which lives below 0x80000.
4] But that's only 3.5MB of the available 4MB. I cannot find what
could possibly be in that space from 0x00000 to 0x80000. The ifiles
(in /lib) all instruct ld(1) to start the user program at 0x80000.
Yup. From the kernels point of view, the world looks like this:
KERNEL 0x400000:--------------------------------------------------------------
KERNEL Kernel dynamic memory pages (for system buffers, etc)
KERNEL 0x380000:--------------------------------------------------------------
USER Shared library area
USER 0x300000:--------------------------------------------------------------
USER User stack
USER 0x2fe???:----------------------
USER User text/data
USER
USER
USER
USER 0x080000:--------------------------------------------------------------
KERNEL User structure (8K)
KERNEL Kernel stack
KERNEL Kernel data
KERNEL Kernel text
KERNEL Interrrupt vector table
KERNEL 0x000000:--------------------------------------------------------------
It looks like that from the perspective of a user program too, except that
the areas labeld KERNEL can't be read by user programs (segfaults). Unix
works by changing the user pages, but the kernel pages are always there.
5] Shouldn't we be able to get 3MB of virtual memory for out programs?
You can, but you have to put some of the code in the shared library
(yes, I know that wasn't what you were looking for). This is actually
pretty reasonable, as long as you *add* it to the existing library image
without distrubing any addresses. There is a package to do this in the
archives, shlib.something.Z. The Directions are pretty obtuse, but it
works.
6]What would happen if some guinea pog modified the ifile to start a program
much lower in memory? How much lower could you safely go? Any takers?
It would crash with a segmentation violation and be very boring.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
A better way to run very large programs would be to use overlays.
This is where a program links several text areas into the same memory space
and does its own swapping. Its pretty common on architectures with very
small address spaces, like PDP-11s, C-64s, etc. The C-128 had some really
slick hardware support for overlays, where they put the OD in ROM, and you
could toggle a register to make it appear in different places in memory.
The idea was to have the OS load your program, and then make the OS go away
and have your program appear in its place. When you needed to make a system
call, you set up the call, toggled the OS back into memory, and jumped. Cute.
Anywho, the system 5 loader is pretty smart, and can do overlays just fine.
You could then toggle the memory in as shared memory or, if your a little
bolder, you could just diddle the page table.
--
################################# :alex.
#Disclaimer: Anyone who agrees # Systems Programmer
#with me deserves what they get.# University of Maryland Baltimore County
################################# alex at umbc3.umbc.edu
More information about the Comp.sys.3b1
mailing list