“Virtual” Memory
How does the OS kernel provide
“private” and “shared” memory areas to
multiple concurrent processes?
Hardware/Firmware/Software
• The PC ‘s memory management system is
a cooperative venture involving hardware,
software, and firmware
• The hardware and firmware would be the
same no matter which Operating System
we choose to run (i.e., Linux or Windows)
• An operating system utilizes the hardware
(in its own unique way) to provide multiple
processes with protected memory-spaces
The Linux/x86 scheme
• Let’s focus on the particular approach that
Linux takes in utilizing the Intel x86 CPU’s
memory-addressing capabilities
• There are two conceptual levels (because
“processor independence” is a goal Linux
strives for): much of the Linux ‘mm’ code
runs on almost any CPU, yet there’s some
code is (unavoidably) specific to the x86
Source-code organization
High-level ‘mm’ code is processor-independent
(It’s in the ‘/usr/src/linux/mm’ subdirectory)
Low-level ‘mm’ code is processor-specific
(It’s in the ‘/usr/src/linux/arch/’ subdirectories)
i386/mm
ppc/mm
mips/mm
alpha/mm
...
Our machines have 1GB of RAM
0x3FFFFFFF
Intel Pentium
CPU
Main
Memory
(1 GB)
0x00000000
system bus
NIC
VGA
FIFO
(4 KB)
VRAM
(32 MB)
some devices
have RAM, too
Booting up
• At power-on, the CPU sees only 1-MB of
the physical memory (including the ROMs)
• The OS initialization code must “activate”
the processor’s “protected-mode” MMU so
that all the ‘Extended Memory’ (including
device-memory) will become addressable
• Finally the OS enables “virtual memory” to
allow the illusion of a 4-GB address-space
Kernel memory-mapping
0xFFFFFFFF
0x3FFFFFFF
1-GB
mappings
896-MB
896-MB
0xC0000000
0x00000000
Physical memory
4-GB
display memory
device memory
0x00000000
Virtual Memory
Application memory-mapping
kernel
space
stack
stack
mappings
text
data
physical memory
user space
data
text
virtual memory
3-GB
‘mm_struct’
• Each application-process uses a different
mapping of physical memory regions into
the Pentium’s “virtual” address-space, so
one process can’t access memory owned
by another process (i.e., private regions)
• The OS switches these mapping when it
suspends one process to resume another
• The ‘map’ for each task is in ‘task_struct’
How Linux tracks mappings
mm_struct
task_struct
vm_area_struct
vma
mm
pgd
start, end, etc
vm_area_struct
start, end, etc
vm_area_struct
start, end, etc
mapping-tables
mapping-tables
mapping-tables
vm_area_struct
start, end, etc
When a program ‘forks()’
• We already know how new processes get
created in the UNIX/Linux environment
(i.e., via the ‘fork()’ function or system-call)
• A child-process gets constructed using the
same code and data as its parent-process
• Yet each task’s memory-regions are kept
‘private’ (i.e., accessible to it alone)
• So how exactly is this feat achieved?
Similar memory-mappings
virtual memory
virtual memory
physical memory
kernel
space
kernel
space
stack
stack
stack
data
data
user space
stack
user space
data
text
data
text
parent-process
text
child-process
Some Linux demos
• We have written a Linux kernel module to
display some info in a task’s ‘mm_struct’
(using a pseudo-file named ‘/proc/mm’)
• We also wrote a program (‘mmfork.cpp’)
that forks a child process, so each task
can read and display its ‘mm_struct’ info
• A user can compare the contents of the
mm_struct’s info for the parent and child
More demos
• We wrote a Linux module (named ‘vma.c’)
that displays information from a task’s list
of ‘vm_area_struct’ data-structures
• You could write a program, similar to our
‘mmfork.cpp’ demo, that would let a user
compare the list of memory-regions which
a parent-process owns and the list that its
child-process has inherited
In-class exercise
• Write an application program that allows a
user to compare BOTH the ‘mm_struct’
and the ‘vm_area_struct’ information that
belong to a parent-process and to its child
• You can use our ‘mm.c’ and ‘vma.c’ Linux
kernel modules, and you can imitate the
programming ideas we used in ‘mmfork’
• TURN IN printouts of your code and output