CH 09

Chapter 9: Main Memory
Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne

Chapter 9: Memory Management
 Background
 Swapping
 Contiguous Memory Allocation
 Segmentation
 Paging
 Structure of the Page Table
 Example: The Intel 32 and 64-bit Architectures
 Example: ARM Architecture
Operating System Concepts – 10 th Edition 9.2 Silberschatz, Galvin and Gagne

Objectives
 To provide a detailed description of various

ways of organizing memory hardware
 To discuss various memory-management
techniques, including paging and segmentation
 To provide a detailed description of the Intel
Pentium, which supports both pure
segmentation and segmentation with paging

Background
 Program must be brought (from disk) into memory and placed

within a process for it to be run
 Main memory and registers are only storage CPU can access
directly
 Memory unit only sees a stream of addresses + read requests,
or address + data and write requests
 Register access in one CPU clock (or less)
 Main memory can take many cycles, causing a stall
 Cache sits between main memory and CPU registers
 Protection of memory required to ensure correct operation

Background
 Kernel vs. user mode
 What is an address space?
 How is it implemented?
Physical memory Abstraction: virtual memory

No protection Each program isolated from
all others and from the OS
Limited size Illusion of infinite memory
Sharing visible to programs Transparent – can’t tell if
memory is shared
Easy to share data between Ability to share code, data
programs

Virtualizing Resources
 Physical Reality:
Different Processes/Threads share the same
hardware
 Need to multiplex CPU (Just finished: scheduling)
 Need to multiplex use of Memory (Today)
 Need to multiplex disk and devices (later in term)
 Why worry about memory sharing?
 The complete working state of a process and/or kernel
is defined by its data in memory (and registers)
 Consequently, cannot just let different threads of
control use the same memory
 Physics: two different pieces of data cannot occupy the
same locations in memory
 Probably don’t want different threads to even have
access to each other’s memory (protection)
Recall: Single and Multithreaded Processes
 Threads encapsulate concurrency

 “Active” component of a process
 Address spaces encapsulate protection
 Keeps buggy program from trashing the system
 “Passive” component of a process

Important Aspects of Memory Multiplexing
 Controlled overlap:
 Separate state of threads should not collide in physical
memory. Obviously, unexpected overlap causes chaos!
 Conversely, would like the ability to overlap when
desired (for communication)
 Translation:
 Ability to translate accesses from one address space
(virtual) to a different one (physical)
 When translation exists, processor uses virtual
addresses, physical memory uses physical addresses
 Side effects:
 Can be used to avoid overlap
 Can be used to give uniform view of memory to programs
 Protection:
 Prevent access to private memory of other processes
 Different pages of memory can be given special behavior
(Read Only, Invisible to user programs, etc).
 Kernel data protected from User programs
 Programs protected from themselves

Base and Limit Registers
 A pair of base and limit registers define the logical
address space
 CPU must check every memory access generated in
user mode to be sure it is between base and limit for
that user

Hardware Address Protection

Address Binding
 Programs on disk, ready to be brought into memory to execute
from an input queue
 Without support, must be loaded into address 0000
 Inconvenient to have first user process physical address
always at 0000
 How can it not be?
 Further, addresses represented in different ways at different
stages of a program’s life
 Source code addresses usually symbolic
 Compiled code addresses bind to relocatable addresses
 i.e. “14 bytes from beginning of this module”
 Linker or loader will bind relocatable addresses to absolute
addresses
 i.e. 74014
 Each binding maps one address space to another

Binding of Instructions and Data to Memory
 Binding of instructions and data to addresses:
 Choose addresses for instructions and data from the standpoint of
the processor
data1: 32dw 0x300 00000020

… … …
start: lw r1,0(data1) 0x900 8C2000C0
jal checkit 0x904 0C000340
loop: addi r1, r1, -1 0x908 2021FFFF
bnz r1, r0, loop 0x90C 1420FFFF
… …
 Could we place data1, start, and/or checkit at different
checkit: …
addresses?
0xD00 …
 Yes
 When? Compile time/Load time/Execution time
 Related: which physical memory locations hold particular
instructions or data?

Binding of Instructions and Data to Memory
 Address binding of instructions and data to memory addresses

can happen at three different stages
 Compile time: If memory location known a priori, absolute
code can be generated; must recompile code if starting
location changes
 Load time: Must generate relocatable code if memory
location is not known at compile time
 Execution time: Binding delayed until run time if the
process can be moved during its execution from one
memory segment to another
 Need hardware support for address maps (e.g., base and
limit registers)

Multistep Processing of a User Program
 Preparation of a program for
execution involves components at:
 Compile time (i.e. “gcc”)
 Link/Load time (unix “ld” does link)
 Execution time (e.g. dynamic libs)
 Addresses can be bound to final
values anywhere in this path
 Depends on hardware support
 Also depends on operating system
 Dynamic Libraries
 Linking postponed until execution
 Small piece of code, stub, used to
locate the appropriate memory-
resident library routine
 Stub replaces itself with the address
of the routine, and executes routine

Operating system organizations
 Uniprogramming without protection
 Early personal computer operating systems: application
always runs at the same place in physical memory,
because each application runs one at a time (application
given illusion of dedicated machine, by giving it reality of
a dedicated machine).
 For example, load application into low memory, operating
system into high memory.
 Application can address any physical memory location.
0x000000 Application
Physical memory
0xFFFFFF OS

Operating system organizations
 Multiprogramming without protection: Linker-loader
 Can multiple programs share physical memory, without
hardware translation?
 Yes: when a program is copied into memory, its
addresses are changed (loads, stores, jumps) to use the
addresses of where the program lands in memory.
 This is done by a linker-loader. Used to be very common.
0x000000 Application1
0x20000 Application2
Physical memory
0xFFFFFF OS
Multiprogramming w/out protection (cont.)
 UNIX ld does the linking portion of this (despite its name

deriving from loading!): compiler generates each .o file with
code that starts at location 0.
 How do you create an executable from this?
 Scan through each .o, changing addresses to point to where
each module goes in larger program (requires help from
compiler to say where all the relocatable addresses are
stored).

Multiprogrammed OS with protection
 Goal of protection:
 Keep user programs from crashing/corrupting OS
 Keep user programs from crashing/corrupting each other
 How is protection implemented?
 Hardware support:
 Address translation
 Dual mode operation: kernel vs. user mode
Application
User mode
Application library
Portable OS layer
Kernel mode
Machine-dependent OS layer
Hardware
Address translation
 Address space: literally, all the addresses a program can
touch. All the state that a program can affect or be affected
by.
 Restrict what a program can do by restricting what it can
touch!
 Hardware translates every memory reference from virtual
addresses to physical addresses; software sets up and
manages the mapping in the translation box.
Physical
Virtual address Translation address
Box (MMU) Physical
CPU memory
Data read or write(untranslated)

Address translation
 Two views of memory:
 View from the CPU – what program sees, virtual memory
 View from memory – physical memory
 Translation box converts between the two views.
 Translation helps implement protection because there’s no way
for programs to even talk about other programs’ addresses; no
way for them to touch operating system code or data.
 Translation can be implemented in any number of ways –
typically, by some form of table lookup (we’ll discuss various
options for implementing the translation box later).
 Separate table for each user address space.

Logical vs. Physical Address Space
 The concept of a logical address space that is bound to a

separate physical address space is central to proper memory
management
 Logical address – generated by the CPU; also referred to as
virtual address
 Physical address – address seen by the memory unit
 Logical and physical addresses are the same in compile-time
and load-time address-binding schemes; logical (virtual) and
physical addresses differ in execution-time address-binding
scheme
 Logical address space is the set of all logical addresses
generated by a program
 Physical address space is the set of all physical addresses
generated by a program

Memory-Management Unit (MMU)
 Hardware device that at run time maps virtual to physical
address
 Many methods possible, covered in the rest of this chapter
 To start, consider simple scheme where the value in the
relocation register is added to every address generated by a
user process at the time it is sent to memory
 Base register now called relocation register
 MS-DOS on Intel 80x86 used 4 relocation registers
 The user program deals with logical addresses; it never sees
the real physical addresses
 Execution-time binding occurs when reference is made to
location in memory
 Logical address bound to physical addresses

Dynamic relocation using a relocation register
 Routine is not loaded until it is

called
 Better memory-space
utilization; unused routine is
never loaded
 All routines kept on disk in
relocatable load format
 Useful when large amounts of
code are needed to handle
infrequently occurring cases
 No special support from the
operating system is required
 Implemented through program
design
 OS can help by providing libraries
to implement dynamic loading

Dynamic Linking
 Static linking – system libraries and program code combined by
the loader into the binary program image
 Dynamic linking –linking postponed until execution time
 Small piece of code, stub, used to locate the appropriate
memory-resident library routine
 Stub replaces itself with the address of the routine, and
executes the routine
 Operating system checks if routine is in processes’ memory
address
 If not in address space, add to address space
 Dynamic linking is particularly useful for libraries
 System also known as shared libraries
 Consider applicability to patching system libraries
 Versioning may be needed

Swapping
 A process can be swapped temporarily out of memory to a
backing store, and then brought back into memory for
continued execution
 Total physical memory space of processes can exceed
physical memory
 Backing store – fast disk large enough to accommodate copies
of all memory images for all users; must provide direct access
to these memory images
 Roll out, roll in – swapping variant used for priority-based
scheduling algorithms; lower-priority process is swapped out
so higher-priority process can be loaded and executed
 Major part of swap time is transfer time; total transfer time is
directly proportional to the amount of memory swapped
 System maintains a ready queue of ready-to-run processes
which have memory images on disk

Swapping (Cont.)
 Does the swapped out process need to swap back in to same
physical addresses?
 Depends on address binding method
 Plus consider pending I/O to / from process memory space
 Modified versions of swapping are found on many systems
(i.e., UNIX, Linux, and Windows)
 Swapping normally disabled
 Started if more than threshold amount of memory allocated
 Disabled again once memory demand reduced below
threshold

Schematic View of Swapping

Context Switch Time including Swapping
 If next processes to be put on CPU is not in memory, need to

swap out a process and swap in target process
 Context switch time can then be very high
 100MB process swapping to hard disk with transfer rate of
50MB/sec
 Swap out time of 2000 ms
 Plus swap in of same sized process
 Total context switch swapping component time of 4000ms
(4 seconds)
 Can reduce if reduce size of memory swapped – by knowing
how much memory really being used
 System calls to inform OS of memory use via
request_memory() and release_memory()

Context Switch Time and Swapping (Cont.)
 Other constraints as well on swapping

 Pending I/O – can’t swap out as I/O would occur to wrong
process
 Or always transfer I/O to kernel space, then to I/O device
 Known as double buffering, adds overhead
 Standard swapping not used in modern operating systems
 But modified version common
 Swap only when free memory extremely low

Swapping on Mobile Systems
 Not typically supported
 Flash memory based
 Small amount of space
 Limited number of write cycles
 Poor throughput between flash memory and CPU on
mobile platform
 Instead use other methods to free memory if low
 iOS asks apps to voluntarily relinquish allocated memory
 Read-only data thrown out and reloaded from flash if
needed
 Failure to free can result in termination
 Android terminates apps if low free memory, but first
writes application state to flash for fast restart
 Both OSes support paging as discussed later

Dual mode operation
 Can application modify its own translation tables? If it
could, could get access to all of physical memory.
 Has to be restricted somehow.
 Dual-mode operation
 When in the OS, can do anything (kernel-mode)
 When in a user program, restricted to only touching
that program’s memory (user-mode)
 Hardware requires CPU to be in kernel-mode to modify
address translation tables.

Dual mode operation
 In Nachos, as well as most OS’s:
 OS runs in kernel mode (untranslated addresses)
 User programs run in user mode (translated addresses)
 Want to isolate each address space so its behavior can’t
do any harm, except to itself.
 A couple of issues:
1. How to share CPU between kernel and user programs
2. How do programs interact?
3. How does one switch between kernel and user modes
when the CPU gets shared between the OS and a user
program?
 OS -> user (kernel –> user mode)
 User -> OS (user mode –> kernel mode)

Dual mode operation
 Kernel -> user:
 To run a user program, create a thread to:
 Allocate and initialize address space control block
 Read program off disk and store in memory
 Allocate and initialize translation table (point to program
memory)
 Run program (or to return to user level after calling the OS
with a system call):
 Set machine registers
 Set hardware pointer to translation table
 Set processor status word (from kernel mode to user
mode)
 Jump to start of program

Dual mode operation
 User-> kernel:
 How does the user program get back into the kernel?
 Voluntarily user->kernel: System call – special
instruction to jump to a specific operating system
handler.
 Just like doing a procedure call into the operating
system kernel – program asks OS kernel, please do
something on procedure’s behalf.
 Can the user program call any routine in the OS?
 No. Just specific ones the OS says are OK (registered
trap handlers)
 Always start running handler at same place, otherwise,
problems!
 How does OS know that system call arguments are as
expected?
 It can’t – OS kernel has to check all arguments –
otherwise, bug in user program can crash kernel.
Dual mode operation
 User-> kernel:
 Involuntarily user->kernel: Hardware interrupt, also
program exception
 Examples of program exceptions:
 Bus error (bad address – e.g., unaligned access)
 Segmentation fault (out of range address)
 Page fault (important for providing illusion of infinite
memory)
 On system call, interrupt, or exception: hardware
atomically
 Sets processor status to kernel mode
 Changes execution stack to an OS kernel stack
 Saves current program counter
 Jumps to handler routine in OS kernel
 Handler saves previous state of any registers it uses
Dual mode operation
 Context switching between programs: same as with
threads, except now also save and restore pointer to
translation table.
 To resume a program, re-load registers, change PSL
(hardware pointer to translation table), and jump to old
PC.
 How does the system call pass arguments? Two choices:
 Use registers.
Can’t pass very much that way.
 Write into user memory, kernel copies into its memory.
Except:
 User addresses – translated
 Kernel addresses – untranslated
 Addresses the kernel sees are not the same addresses
as what the user sees!
Communication between address spaces
 How do two address spaces communicate? Can’t do it
directly if address spaces don’t share memory.
 Instead, all inter-address space (in UNIX, inter-process)

communication has to go through kernel, via system calls.
 Models of inter-address space communication:

 Byte stream producer/consumer. For example,
communicate through pipes connecting stdin/stdout.
 Message passing (send/receive). Will explain later how
you can use this to build remote procedure call (RPC)
abstraction, so that you can have one program call a
procedure in another.

Models of inter-address space communication (cont’d)
 File system (read and write files). File system is

shared state! (Even though it exists outside of any
address space.)
 “Shared Memory” -- Alternately, on most UNIXes, can
ask kernel to set up address spaces to share a region
of memory, but that violates the whole notion of why
we have address spaces – to protect each program
from bugs in the other programs.

Communication between address spaces
 In any of these, once you allow communication, bugs
from one program can propagate to those it
communicates with, unless each program verifies that
its input is as expected.
 So why do UNIXes support shared memory?
 One reason is that it provides a cheap way to
simulate threads on systems that don’t support
them:
 Each UNIX process = Heavyweight thread.

An Example of Application – Kernel Interaction:
Shells and UNIX fork
 Shell – user program (not part of the kernel!)
 Prompts users to type command
 Does system call to run command
 In Nachos, system call to run command is simply “exec”. But

UNIX works a bit differently than Nachos.
 UNIX idea: separate notion of fork vs. exec

 Fork – create a new process, exact copy of current one
 Exec – change current process to run different program

 To run a program in UNIX:
 Fork a process
 In child, exec program
 In parent, wait for child to finish
 UNIX fork:
 Stop current process
 Create exact copy + mark one register in child
 Put on ready list
 Resume original
 Original has code/data/stack. Copy has exactly the same
thing!

 Only difference between child and parent is: UNIX changes
one register in child before resume.
 Child process:
 Exec program:
 Stop process
 Copy new program over current one
 Resume at location 0
 Justification was to allow I/O (pipes, redirection, etc.), to be

set up between fork and exec.
 Child can access shell’s data structures to see whether
there is any I/O redirection, and then sets it up before exec.
 Nachos simply combines UNIX fork and exec into one

operation.

Protection without hardware support
 Does protection require hardware support?
 In other words, do we really need hardware address
translation and an unprivileged user mode?
 No! Can put two different programs in the same hardware
address space, and be guaranteed that they can’t trash
each other’s code or data.
 Two approaches: strong typing and software fault isolation.

Protection via strong typing
 Restrict programming language to make it impossible to
misuse data structures, so can’t express program that would
trash another program, even in same address space.
 Examples of strongly typed languages include LISP, Cedar,
Ada, Modula-3, and most recently, Java.
 Note: nothing prevents shared data from being trashed;

which includes the data that exists in the file system .
 Even in UNIX, there is nothing to keep programs you run from
deleting all your files (but at least can’t crash the OS!)

Protection via strong typing
 Java’s solution: programs written in Java can be downloaded
and run safely, because language/compiler /runtime prevents
the program (also called an applet) from doing anything bad (for
example, can’t make system calls, so can’t touch files).
Application written in Java

Java runtime library
Native operating system (kernel

mode or unprotected
Java operating system structure
 Java also defines portable virtual machine layer, so any Java
programs can run anywhere, dynamically compiled onto native
machine.

Protection via software fault isolation
 Language independent approach: Have compiler generate
object code that provably can’t step out of bounds –
programming language independent.
 Easy for compiler to statically check that program doesn’t do

any native system calls.
 How does the compiler prevent a pointer from being

misused, or a jump to an arbitrary place in the (unprotected)
OS?

 Insert code before each “store” and “indirect branch”
instruction;
 check that address is in bounds.
 For example:
store r2, (r1)
 becomes
assert “safe” is a legal address
copy r1 into “safe”
check safe is still legal
store r2, (safe)

 Note that I need to handle case where malicious user inserts
a jump past the check; “safe” always holds a legal address,
malicious user can’t generate illegal address by jumping past
check.
 Key to good performance is to apply aggressive compiler

optimizations to remove as many checks as possible
statically.
 Research result is protection can be provided in language

independent way for < 5% overhead.

Example applications of software protection
 Safe downloading of programs onto local machine over Web:
games, interactive advertisements, etc.
 Safe anonymous remote execution over Web: Web server could

provide not only data, but also computing.
 Plug-ins: Complex application built by multiple vendors (example:

Chrome support for new document formats).
 Need to isolate failures in plug-in code from killing main

application, but slow to put each piece in separate address space.
 Kernel plug-ins. Drop application-specific code into OS kernel, to

customize its behavior (ex: to use a CPU scheduler tuned for
database needs, or CAD needs, etc.)

Contiguous Allocation
 Main memory must support both OS and user
processes
 Limited resource, must allocate efficiently
 Contiguous allocation is one early method
 Main memory usually into two partitions:
 Resident operating system, usually held in low
memory with interrupt vector
 User processes then held in high memory
 Each process contained in single contiguous
section of memory
 Each program loaded into contiguous regions of
physical memory, but with protection between
programs.

Contiguous Allocation (Cont.)
 Relocation registers used to protect user processes from
each other, and from changing operating-system code and
data
 relocation: physical addr = virtual addr + base register
 protection: check that address falls in (base, base+limit)
 Base register contains value of smallest physical address
 Limit register contains range of logical addresses – each
logical address must be less than the limit register
 MMU maps logical address dynamically
 Can then allow actions such as kernel code being
transient and kernel changing size

Hardware Support for Relocation and Limit Registers

Base and Limit
 Program has illusion it is running on its own dedicated
machine, with memory starting at 0 and going up to size =
limit.
 Like linker-loader, program gets contiguous region of
memory.
 But unlike linker-loader, protection: program can only touch
locations in physical memory between base and base + limit.
0
6250
Code
Data
limit
Virtual memory stack
6250 + limit
Physical memory
Base and Limit
 Provides level of indirection: OS can move bits around behind
the program’s back, for instance, if program needs to grow
beyond its bounds, or if need to coalesce fragments of
memory.
 Stop program, copy bits, change base and bounds registers,
restart.
 Only the OS gets to change the base and bounds! Clearly,

user program can’t, or else lose protection.

Base and Bounds
 With base&limit system, what gets saved/restored on a
context switch?
 Everything from before + base/limit values
 Complete contents of memory out to disk (Called
“Swapping”)
 Hardware cost:
 2 registers, Adder, Comparator
 Plus, slows down hardware because need to take time to
do add/compare on every memory reference.

Base and Limit tradeoffs
 Pros:
 Simple, fast
 Cons:
1. Hard to share between programs
 For example, suppose two copies of “vi”
 Want to share code
 Want data and stack to be different
 Can’t do this with base and bounds!
2. Complex memory allocation
3. Doesn’t allow heap, stack to grow dynamically – want to
put these as far apart as possible in virtual memory, so
that they can grow to whatever size is needed.

Multiple-partition allocation
 Multiple-partition allocation
 Degree of multiprogramming limited by number of partitions
 Variable-partition sizes for efficiency (sized to a given process’
needs)
 Hole – block of available memory; holes of various size are
scattered throughout memory
 When a process arrives, it is allocated memory from a hole large
enough to accommodate it
 Process exiting frees its partition, adjacent free partitions
combined
 Operating system maintains information about:
a) allocated partitions b) free partitions (hole)

Dynamic Storage-Allocation Problem
 How to satisfy a request of size n from a list of free holes?
 First-fit: Allocate the first hole that is big enough
 Best-fit: Allocate the smallest hole that is big enough;

must search entire list, unless ordered by size
 Produces the smallest leftover hole
 Worst-fit: Allocate the largest hole; must also search

entire list
 Produces the largest leftover hole
 First-fit and best-fit better than worst-fit in terms of speed

and storage utilization
 Particularly bad if want address space to grow dynamically
(e.g., the heap).

Internal Fragmentation
OS
Process 7
Process 4 Hole of 18,464 bytes

Process 4 request for
18,462 bytes
Internal fragment of
2 bytes
Process 2
 Internal Fragmentation – allocated memory may be slightly

larger than requested memory but not being used.
 this size difference is memory internal to a partition, but
not being used

External Fragmentation
 External Fragmentation - total memory space exists to
satisfy request but it is not contiguous
 50-percent rule: 1/3 of memory may be unusable.
 Given N allocated blocks, another 0.5N blocks will be lost
due to fragmentation.
OS
50k
process 3
125k Process 9 ?
process 8
100k
Operating System Concepts – 10 th Edition 9.60 process 2

Silberschatz, Galvin and Gagne
Compaction
 Shuffle memory contents to place all free memory together in one
large block
 Only if relocation dynamic, and is done at execution time
 Same I/O DMA problem
 Latch job in memory while it is involved in I/O
 Do I/O only into OS buffers
 Now consider that backing store has same fragmentation problems
OS OS OS
50k process 3
process 3 90k
125k Process 9 process 8
process 8 60k process 8
process 3
100k
process 2 process 2 process 2
Segmentation
 Memory-management scheme that supports user view of
memory
 A segment is a region of logically contiguous memory
 A program is a collection of segments
 A segment is a logical unit such as:
main program
procedure
function
method
object
local variables, global variables
common block
stack
symbol table
arrays

User’s View of a Program

Logical View of Segmentation
4
1
3 2
4
user space physical memory space

Segmentation Architecture
 Idea is to generalize base and limit, by allowing a table of
base&limit pairs
 Logical address consists of a two tuple: <segment-number,
offset>
 Segment table – maps two-dimensional user defined address into

one-dimensional physical addresses; each table entry has:
 base – contains the starting physical address where the
segments reside in memory
 limit – specifies the length of the segment
 Hardware support:
 Segment-table base register (STBR) points to the segment table’s
location in memory
 Segment-table length register (STLR) indicates number of

segments used by a program;
segment number s is legal if s < STLR

Segmentation Architecture (Cont.)
 Protection
 With each entry in segment table associate:
 validation bit = 0  illegal segment
 read/write/execute privileges
 Protection bits associated with segments; code sharing
occurs at segment level
 Since segments vary in length, memory allocation is a
dynamic storage-allocation problem
 A segmentation example is shown in the following diagram

Segmentation Hardware

Segmentation example
 Assume 14 bit addresses divided up as:
 2 bit segment ID (1st digit), and a 12 bit segment offset
(last 3).
Virtual memory physical memory
0 0
Seg base limit 6ff 4ff
1000
0 code 0x4000 0x700 14ff 2000
1 Data 0x0000 0x500
2fff
2 -
3000
3 Stack 0x2000 0x1000
3fff
Segment table
where is 0x0240?
0x1108? 4000
0x265c?
46ff
0x3002?
Operating System Concepts – 10 th 0x1600?
Edition 9.68 Silberschatz, Galvin and Gagne
Observations about Segmentation
 This should seem a bit strange: the virtual address space
has gaps in it!
 Each segment gets mapped to contiguous locations in
physical memory, but may be gaps between segments.
 But a correct program will never address gaps; if it does,
trap to kernel and then core dump.
 Minor exception: stack, heap can grow.
 In UNIX, sbrk() increases size of heap segment.
 For stack, just take fault, system automatically increases
size of stack.

Observations about Segmentation cont’d
 Detail: Need protection mode in segmentation table.
 For example, code segment would be read-only (only
execution and loads are allowed).
 Data and stack segment would be read-write (stores
allowed).
 What must be saved/restored on context switch?

 Typically, segment table stored in CPU, not in memory,
because it’s small.
 Might store all of processes memory onto disk when
switched (called “swapping”)

Segment Translation Example
 Example: What happens with the segment table
shown earlier, with the following as virtual
memory contents? Code does:
Physical memory
Virtual memory strlen(x); Initially PC = 240
Main: 240 store 1108, r2 x: 108 666
244 store pc +8, r31 …
248 jump 360 Main: 4240 store 1108, r2
24c … 4244 store pc +8, r31
… 4248 jump 360
Strlen: 360 loadbyte (r2), r3 424c …
… ...
420 jump (r31) Strlen: 4360 loadbyte (r2), r3
… …
x: 1108 a b c \0
Operating System Concepts – 10 th Edition 9.71
4420 jump (r31)
Segmentation Tradeoffs
 Pro:
 Efficient for sparse address spaces
 Multiple segments per process
 Easy to share whole segments (for example, code
segment)
 Don’t need entire process
in memory!!!
 Con:
 Complex memory allocation
 Extra layer of translation
speed = hardware support
 Still need first fit, best fit, etc., and re-shuffling to
coalesce free fragments, if no single free space is big
enough for a new segment.
 How do we make memory allocation simple and easy?

Paging
 Physical address space of a process can be noncontiguous;
process is allocated physical memory whenever the latter is
available
 Avoids external fragmentation
 Avoids problem of varying sized memory chunks
 Divide physical memory into fixed-sized blocks called frames
 Size is power of 2, between 512 bytes and 16 Mbytes
 Divide logical memory into blocks of same size called pages
 Keep track of all free frames
 To run a program of size N pages, need to find N free frames and
load program
 Simpler, because allows use of a bitmap. What’s a bitmap?
001111100000001100
 Each bit represents one page of physical memory – 1 means
allocated, 0 means unallocated.
 Lots simpler than base&limit or segmentation

Address Translation Scheme
 Set up a page table to translate logical to physical addresses
 Backing store likewise split into pages
 Still have Internal fragmentation
 Address generated by CPU is divided into:
 Page number (p) – used as an index into a page table which
contains base address of each page in physical memory
 Page offset (d) – combined with base address to define the
physical memory address that is sent to the memory unit
page number page offset

p d
m -n n
 For given logical address space 2m and page size 2n

Paging Hardware
 Operating system controls mapping: any page of virtual
memory can go anywhere in physical memory

Paging Model of Logical and Physical Memory

Paging Example
n=2 and m=4 32-byte memory and 4-byte pages

Paging Tradeoffs
 What needs to be saved/restored on a context switch?
 Page table pointer and limit
 Advantages
 no external fragmentation (no compaction)
 relocation (now pages, before were processes)
 Disadvantages
 internal fragmentation
 Page size = 2,048 bytes, Process size = 72,766 bytes
– 35 pages + 1,086 bytes = 962 bytes fragment
 Worst case = 1 frame – 1 byte; average = 1/2 frame per
process
 So small frame sizes desirable?
 But each page table entry takes memory to track
 Page sizes growing over time
 Solaris supports two page sizes – 8 KB and 4 MB
 Process view and physical memory now very different
 System Concepts – 10th Edition
By implementation process can
Operating 9.78 only access its own memory
Free Frames
 Frame table: keeps track of which frames are allocated and
which are free.
Before allocation After allocation

Implementation of Page Table
 Page table kept in registers
 Fast!
 Only good when number of frames is small
 Expensive!
 Instructions to load or modify the page-table registers are
privileged.
Registers
Memory
Disk
Implementation of Page Table
 Page table is kept in main memory
 Page-table base register (PTBR) points to the page table
 Page-table length register (PTLR) indicates size of the page table
 In this scheme every data/instruction access requires two
memory accesses
 One for the page table and one for the data / instruction
 The two memory access problem can be solved by the use of a
special fast-lookup hardware cache called associative memory
or translation look-aside buffers (TLBs)
0 2 1
0
1 1
PTBR
Page table
2
Virtual
memory 3
Physical memory
Implementation of Page Table (Cont.)
 Some TLBs store address-space identifiers (ASIDs) in each
TLB entry – uniquely identifies each process to provide
address-space protection for that process
 Otherwise need to flush at every context switch
 TLBs typically small (64 to 1,024 entries)
 On a TLB miss, value is loaded into the TLB for faster access
next time
 Replacement policies must be considered (LRU, random,
etc.)
 Some entries can be wired down for permanent fast
access

Associative Memory
 Associative memory – parallel search

P a ge # F ra m e #
 Address translation (p, d)

 If p is in associative register, get frame # out
 Otherwise get frame # from page table in memory

Translation Look-aside Buffer (TLB)

Paging Hardware With TLB

Effective Access Time
 Associative Lookup =  time unit
 Can be < 10% of memory access time
 Hit ratio = 
 Hit ratio – percentage of times that a page number is
found in the associative registers; ratio related to number
of associative registers
 Assume memory cycle time is 1 microsecond
 Effective Access Time (EAT)
EAT = (1 + )  + (2 + )(1 – )
=2+–
 Consider  = 80%,  = 20ns for TLB search, 100ns for memory
access
 EAT = 0.80 x 120 + 0.20 x 220 = 140ns
 Consider more realistic hit ratio ->  = 99%,  = 20ns for TLB
search, 100ns for memory access
 EAT = 0.99 x 120 + 0.01 x 220 = 121ns

Memory Protection
 Memory protection implemented by associating protection bit
with each frame to indicate if read-only or read-write access is
allowed
 Can also add more bits to indicate page execute-only, and
so on
 Valid-invalid bit attached to each entry in the page table:
 “valid” indicates that the associated page is in the process’
logical address space, and is thus a legal page
 “invalid” indicates that the page is not in the process’
logical address space
 Or use page-table length register (PTLR)
 Any violations result in a trap to the kernel

Valid (v) or Invalid (i) Bit In A Page Table
 14-bit address space –

 0 to 16,383
 Program’s addresses –
 0 to 10,468
 beyond 10,468 is illegal
 Page 5 classified as valid
 Due to 2K page size,
 internal fragmentation

Shared Pages
 Shared code
 One copy of read-only (reentrant) code shared among
processes (i.e., text editors, compilers, window systems)
 Similar to multiple threads sharing the same process
space
 Also useful for interprocess communication if sharing of
read-write pages is allowed
 Private code and data
 Each process keeps a separate copy of the code and data
 The pages for the private code and data can appear
anywhere in the logical address space

Shared Pages Example

Structure of the Page Table
 Memory structures for paging can get huge using straight-forward
methods
 Consider a 32-bit logical address space as on modern
computers
 Page size of 4 KB (212)
 Page table would have 1 million entries (232 / 212 = 220)
 If each entry is 4 bytes -> 4 MB of physical address space /
memory for page table alone
 That amount of memory used to cost a lot
 Don’t want to allocate that contiguously in main memory
 Solution
– divide the page table into smaller pieces (Page the page
table)
 Hierarchical Paging
 Hashed Page Tables
 Inverted Page Tables

Hierarchical Page Tables
 Break up the logical address space into multiple page
tables
 A simple technique is a two-level page table
 We then page the page table

Two-Level Page-Table Scheme

Two-Level Paging Example
 A logical address (on 32-bit machine with 1K page size) is
divided into:
 a page number consisting of 22 bits
 a page offset consisting of 10 bits
 Since the page table is paged, the page number is further

divided into:
 a 12-bit page number
 a 10-bit page offset
 Thus, a logical address is as follows:
 where p1 is an index into the outer page table, and p2 is the

displacement within the page of the inner page table
 Known as forward-mapped page table

Address-Translation Scheme

64-bit Logical Address Space
 Even two-level paging scheme not sufficient

 If page size is 4 KB (212)
 Then page table has 252 entries
 If two level scheme, inner page tables could be 2 10 4-byte
entries
 Address would look like
 Outer page table has 242 entries or 244 bytes

 One solution is to add a 2nd outer page table
 But in the following example the 2nd outer page table is
still 234 bytes in size
 And possibly 4 memory access to get to one physical
memory location

Three-level Paging Scheme
 On context-switch: save single PageTablePtr

 Sometimes, top-level page tables called “directories” (Intel)
 Each entry called a Page Table Entry (PTE)

What is in a Page Table Entry (PTE)?
 Pointer to next-level page table or to actual page
 Permission bits: valid, read-only, read-write, write-only
 Example: Intel x86 architecture PTE:
 Address same format previous slide (10, 10, 12-bit offset)
 Intermediate page tables called “Directories”
Free
PWT
PCD
Physical Frame Number 0 L D A UW P
(OS)
31-12 (same as “valid”
P: Present 11-9bit 8
in 7other
6 5 4 3 2 1 0
architectures)
W: Writeable
U: User accessible
PWT: Page write transparent: external cache write-
through
PCD: Page cache disabled (page cannot be cached)
A: Accessed: page has been accessed recently
D: Dirty (PTE only): page has been modified
recently
L: L=14MB page (directory only).
Bottom 22 bits of virtual address Silberschatz,
serve as offset
Galvin and Gagne
Operating System Concepts – 10 th Edition 9.98
Examples of how to use a PTE
 How do we use the PTE?
 Invalid PTE can imply different things:
 Region of address space is actually invalid or
 Page/directory is just somewhere else than memory
 Validity checked first
 OS can use other (say) 31 bits for location info
 Usage Example: Demand Paging
 Keep only active pages in memory
 Place others on disk and mark their PTEs invalid
 Usage Example: Copy on Write
 UNIX fork gives copy of parent address space to child
 Address spaces disconnected after child created
 How to do this cheaply?
 Make copy of parent’s page tables (point at same memory)
 Mark entries in both sets of page tables as read-only
 Page fault on write creates two copies
 Usage Example: Zero Fill On Demand
 New data pages must carry no information (say be
zeroed)
 Mark PTEs as invalid; page fault on use gets zeroed page
 Often, OS creates zeroed pages in background

How is the translation accomplished?
 What, exactly happens inside MMU?

 One possibility: Hardware Tree Traversal
 For each virtual address, takes page table base pointer and
traverses the page table in hardware
 Generates a “Page Fault” if it encounters invalid PTE
 Fault handler will decide what to do
 More on this next lecture
 Pros: Relatively fast (but still many memory accesses!)
 Cons: Inflexible, Complex hardware
 Another possibility: Software
 Each traversal done in software
 Pros: Very flexible
 Cons: Every translation must invoke Fault!
 In fact, need way to cache translations for either case!

Caching Concept
 Cache: a repository for copies that can be accessed more

quickly than the original
 Make frequent case fast and infrequent case less dominant
 Caching underlies many of the techniques that are used today to
make computers fast
 Can cache: memory locations, address translations, pages,
file blocks, file names, network routes, etc…
 Only good if:
 Frequent case frequent enough and
 Infrequent case not too expensive
 Important measure: Average Access time =
(Hit Rate x Hit Time) + (Miss Rate x Miss Time)

Why Bother with Caching?
Processor-DRAM Memory Gap (latency)

1000 CPU
µProc
“Moore’s Law” 60%/yr.
(really Joy’s Law) (2X/1.5yr)
Performance
100 Processor-Memory
Performance Gap:
(grows 50% / year)
10
“Less’ Law?” DRAM
DRAM
9%/yr.
1 (2X/10
yrs)
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
Time
Hashed Page Tables
 Common in address spaces > 32 bits
 The virtual page number is hashed into a page table
 This page table contains a chain of elements hashing to the
same location
 Each element contains (1) the virtual page number (2) the value
of the mapped page frame (3) a pointer to the next element
 Virtual page numbers are compared in this chain searching for a
match
 If a match is found, the corresponding physical frame is
extracted
 Variation for 64-bit addresses is clustered page tables
 Similar to hashed but each entry refers to several pages
(such as 16) rather than 1
 Especially useful for sparse address spaces (where memory
references are non-contiguous and scattered)

Hashed Page Table

Hashed Page Table
 Independent of size of address space,
 Pro:
 O(1) lookup to do translation
 Requires page table space proportional to how many
pages are actually being used, not proportional to size of
address space – with 64 bit address spaces, this is a big
win!
 Con:
 Overhead of managing hash chains, etc.

Inverted Page Table
 Rather than each process having a page table and keeping track
of all possible logical pages, track all physical pages
 One entry for each real (physical) page of memory
 Entry consists of the virtual address of the page stored in that real
memory location, with information about the process that owns
that page
 Address-space identifier (ASID) stored in each entry maps logical

page for a particular process to the corresponding physical page
frame.
 Decreases memory needed to store each page table, but increases

time needed to search the table when a page reference occurs

Inverted Page Table Architecture

Inverted Page Table
 Pro:
 Decreases memory needed to store each page table
 Con:
 increases time needed to search the table
 Use hash table to limit the search to one — or at most a few —

page-table entries
 One virtual memory reference requires at least two real memory
reads: one for the hash table entry and one for the page table.
 Associative registers (TLBs) can be used to improve
performance.
 But how to implement shared memory?
 One mapping of a virtual address to the shared physical
address

Paging + segmentation: best of both?
 simple memory allocation,
 easy to share memory, and
 efficient for sparse address spaces
Virtual address
virt seg # virt page # offset Physical address
phys frame# offset
No
page-table page-table > error
base size
yes
Segment table
Physical memory
+ Phys frame #
Operating System Concepts – 10 th Edition 9.109Page table Silberschatz, Galvin and Gagne
Paging + segmentation
 Questions:
1. What must be saved/restored on context switch?
2. How do we share memory? Can share entire
segment, or a single page.
 Example: 24 bit virtual addresses = 4 bits of
segment #, 8 bits of virtual page #, and 12 bits of
offset.
Segment table Physical memory
Page-table base Page-table size 0x1000 0x6 What do the
0xb following addresses
0x2000 0x14 0x4 translate to?
– – …
0x1000 0xD 0x2000 0x13 0x002070?
– – 0x2a 0x201016 ?
0x3 0x14c684 ?
… 0x210014 ?
portions of the page tables
Operating System Concepts – 10 th Edition 9.110 for the segments Silberschatz, Galvin and Gagne
Multilevel translation
 What must be saved/restored on context switch?
 Contents of top-level segment registers (for this example)
 Pointer to top-level table (page table)
 Pro:
 Only need to allocate as many page table entries as we
need.
 In other words, sparse address spaces are easy.
 Easy memory allocation
 Share at segment or page level (need additional reference
counting)
 Cons:
 Pointer per page (typically 4KB - 16KB pages today)
 Page tables need to be contiguous
 Two (or more, if > 2 levels) lookups per memory reference

Another Major Reason to Deal with Caching
 Cannot afford to translate on every access

 At least two DRAM accesses per actual DRAM access
 Or: perhaps I/O if page table partially on disk!
 Even worse: What if we are using caching to make memory

access faster than DRAM access???
 Solution? Cache translations!

 Translation Cache: TLB (“Translation Look-aside Buffer”)

Why Does Caching Help? Locality!
Probability
of reference
0 2n - 1
Address Space
 Temporal Locality (Locality in Time):
 Keep recently accessed data items closer to
processor
 Spatial Locality (Locality in Space):
 Move contiguous blocks to the upper levels
Lower Level
To Processor Upper Level Memory
Memory
Blk X
From Processor Blk Y

Memory Hierarchy of a Modern Computer System
 Take advantage of the principle of locality to:

 Present as much memory as in the cheapest technology
 Provide access at speed offered by the fastest technology
Processor
Control
Tertiary
Secondary
Storage
Second Storage
Main (Tape)
Level (Disk)
On-Chip
Registers
Memory
Cache
Datapath Cache (DRAM)

(SRAM)
Speed (ns): 1s 10s-100s 100s 10,000,000s 10,000,000,000s

(10s sec)
(10s ms)
OperatingSize (bytes):
System Concepts100s
– 10 th Edition Ks-Ms 9.114 Ms Gs Silberschatz, Galvin
Tsand Gagne
A Summary on Sources of Cache Misses
 Compulsory (cold start): first reference to a block

 “Cold” fact of life: not a whole lot you can do about it
 Note: When running “billions” of instruction, Compulsory
Misses are insignificant
 Capacity:
 Cache cannot contain all blocks access by the program
 Solution: increase cache size
 Conflict (collision):
 Multiple memory locations mapped to same cache location
 Solutions: increase cache size, or increase associativity
 Two others:
 Coherence (Invalidation): other process (e.g., I/O) updates
memory
 Policy: Due to non-optimal replacement policy

How is a Block found in a Cache?
 Index Used to Lookup Candidates in Cache

 Index identifies the set
 Tag used to identify actual copy
 If no candidates match, then declare cache miss
 Block is minimum quantum of caching
 Data select field used to select data within block
 Many caching applications don’t have data select field
Review: Direct Mapped Cache
 Direct Mapped 2N byte cache:
 The uppermost (32 - N) bits are always the Cache
Tag
 The lowest M bits are the Byte Select (Block Size =
2M)
 Example: 1 KB Direct Mapped Cache with 32 B
Blocks
 Index chooses potential block
31 Tag checked to verify block 9 4 0
 Byte select chooses byte within
Cache Tag Cacheblock
Index Byte Select
Ex: 0x01 Ex: 0x00
Ex: 0x50
Valid Bit Cache Tag Cache Data

Byte 31 Byte 1 Byte 0 0
: :
0x50 Byte 63 Byte 33 Byte 32 1
2
3
: : :
Byte 1023 Byte 992 31
Operating System Concepts – 10 th Edition 9.117 : Silberschatz, Galvin and Gagne
Review: Set Associative Cache
 N-way set associative: N entries per

Cache Index
 N direct mapped caches operates in
parallel
 Example: Two-way set associative

cache
 Cache Index selects a “set” from the cache
 Two tags in the set are compared to input
in parallel
 Data is selected based on the tag result

Set Associative Cache Example
31 8 4 0
Cache Tag Cache Index Byte Select
Valid Cache Tag Cache Data Cache Data Cache Tag Valid
Cache Block 0 Cache Block 0
: : : : : :
Compare Compare
Sel1 1 Mux 0 Sel0
OR
Operating System Concepts – 10 th Edition Hit 9.119 Cache Block Silberschatz, Galvin and Gagne
Review: Fully Associative
Cache
 Fully Associative: Every block can hold any line
 Address does not include a cache index
 Compare Cache Tags of all Cache Entries in
Parallel
 Example: Block Size=32B blocks

 We need N 27-bit comparators
 Still have byte select to choose from within
block

Fully Associative Cache example
31 4 0
Cache Tag (27 bits long) Byte Select
Ex: 0x01
Cache Tag Valid Bit Cache Data

= Byte 31 Byte 1 Byte 0
: :
= Byte 63 Byte 33 Byte 32
=
=
=
: : :

Where does a Block Get Placed in a Cache?
 Example: Block 12 placed in 8 block cache

32-Block Address Space:
Block 1111111111222222222233
no. 01234567890123456789012345678901
Direct mapped: Set associative: Fully associative:

block 12 can go block 12 can go block 12 can go
only into block 4 anywhere in set 0 anywhere
(12 mod 8) (12 mod 4)
Block 01234567 Block 01234567 Block 01234567
no. no. no.
Set Set Set Set

Operating System Concepts – 10 th Edition 0 1 9.122
2 3 Silberschatz, Galvin and Gagne
Review: Which block should be replaced on a miss?
 Easy for Direct Mapped: Only one possibility

 Set Associative or Fully Associative:
 Random
 LRU (Least Recently Used)
2-way 4-way 8-way

Size LRU Random LRU Random LRU Random
16 KB 5.2% 5.7% 4.7% 5.3% 4.4% 5.0%
64 KB 1.9% 2.0% 1.5% 1.7% 1.4% 1.5%
256 KB 1.15% 1.17% 1.13% 1.13% 1.12% 1.12%

Review: What happens on a write?
 Write through: The information is written to both the block in the

cache and to the block in the lower-level memory
 Write back: The information is written only to the block in the
cache.
 Modified cache block is written to main memory only when it
is replaced
 Question is block clean or dirty?
 Pros and Cons of each?
 WT:
 PRO: read misses cannot result in writes
 CON: Processor held up on writes unless writes buffered
 WB:
 PRO: repeated writes not sent to DRAM
processor not held up on writes
 CON: More complex
Read miss may require write back of dirty
data

Caching Applied to Address Translation
Virtual TLB
Address Physical
Cached?
Address
CPU Yes
No
Physical
ve Memory
t
S a sul
R e
Translate
(MMU)
Data Read or Write

(untranslated)
 Question is one of page locality: does it exist?
 Instruction accesses spend a lot of time on the same page
(since accesses sequential)
 Stack accesses have definite locality of reference
 Data accesses have less page locality, but still some…
 Can we have a TLB hierarchy?
 Sure: multiple levels at different sizes/speeds

What Actually Happens on a TLB Miss?
 Hardware traversed page tables:
 On TLB miss, hardware in MMU looks at current page table to
fill TLB (may walk multiple levels)
 If PTE valid, hardware fills TLB and processor never knows
 If PTE marked as invalid, causes Page Fault, after which
kernel decides what to do afterwards
 Software traversed Page tables (like MIPS)
 On TLB miss, processor receives TLB fault
 Kernel traverses page table to find PTE
 If PTE valid, fills TLB and returns from fault
 If PTE marked as invalid, internally calls Page Fault
handler
 Most chip sets provide hardware traversal
 Modern operating systems tend to have more TLB faults
since they use translation for many things
 Examples:
 shared segments
 user-level portions of an operating system

What happens on a Context Switch?
 Need to do something, since TLBs map virtual addresses to
physical addresses
 Address Space just changed, so TLB entries no longer
valid!
 Options?
 Invalidate TLB: simple but might be expensive
 What if switching frequently between processes?
 Include ProcessID in TLB
 This is an architectural solution: needs hardware
 What if translation tables change?
 For example, to move page from memory to disk or vice
versa…
 Must invalidate TLB entry!
 Otherwise, might think that page is still in memory!

What TLB organization makes sense?
CPU TLB Cache Memory
 Needs to be really fast

 Critical path of memory access
 In simplest view: before the cache
 Thus, this adds to access time (reducing cache speed)
 Seems to argue for Direct Mapped or Low Associativity
 However, needs to have very few conflicts!
 With TLB, the Miss Time extremely high!
 This argues that cost of Conflict (Miss Time) is much higher
than slightly increased cost of access (Hit Time)
 Thrashing: continuous conflicts between accesses
 What if use low order bits of page as index into TLB?
 First page of code, data, stack may map to same entry
 Need 3-way associativity at least?
 What if use high order bits as index?
 TLB mostly unused for small programs
TLB organization: include protection
 How big does TLB actually have to be?

 Usually
small: 128-512 entries
 Not very big, can support higher associativity
 TLB usually organized as fully-associative cache
 Lookup is by Virtual Address
 Returns Physical Address + other info
 What happens when fully-associative is too slow?
 Put a small (4-16 entry) direct-mapped cache in front
 Called a “TLB Slice”
 Example for MIPS R3000:
Virtual Address Physical Address Dirty Ref Valid Access ASID

0xFA00 0x0003 Y N Y R/W 34
0x0040 0x0010 N Y Y R 0
0x0041 0x0011 N Y Y R 0

Oracle SPARC Solaris
 Consider modern, 64-bit operating system example with
tightly integrated HW
 Goals are efficiency, low overhead
 Based on hashing, but more complex
 Two hash tables
 One kernel and one for all user processes
 Each maps memory addresses from virtual to physical
memory
 Each entry represents a contiguous area of mapped virtual
memory,
 More efficient than having a separate hash-table entry
for each page
 Each entry has base address and span (indicating the
number of pages the entry represents)

Oracle SPARC Solaris (Cont.)
 TLB holds translation table entries (TTEs) for fast hardware
lookups
 A cache of TTEs reside in a translation storage buffer (TSB)
 Includes an entry per recently accessed page
 Virtual address reference causes TLB search
 If miss, hardware walks the in-memory TSB looking for the
TTE corresponding to the address
 If match found, the CPU copies the TSB entry into the
TLB and translation completes
 If no match found, kernel interrupted to search the hash
table
– The kernel then creates a TTE from the appropriate
hash table and stores it in the TSB, Interrupt handler
returns control to the MMU, which completes the
address translation.

Example: The Intel 32 and 64-bit Architectures
 Dominant industry chips
 Pentium CPUs are 32-bit and called IA-32 architecture
 Current Intel CPUs are 64-bit and called IA-64

architecture
 Many variations in the chips, cover the main ideas here

Example: The Intel IA-32 Architecture
 Memory management in IA-32 systems is divided into two
components—segmentation and paging
 The CPU generates logical addresses, which are given to
the segmentation unit.
 The segmentation unit produces a linear address for each
logical address.
 The linear address is then given to the paging unit, which
in turn generates the physical address in main memory.
 The segmentation and paging units form the equivalent of
the memory-management unit (MMU).

IA-32 Segmentation
 Each segment can be 4 GB
 Up to 16 K segments per process
 Divided into two partitions
 First partition of up to 8 K segments are private to process
(kept in local descriptor table (LDT))
 Second partition of up to 8K segments shared among all
processes (kept in global descriptor table (GDT))
 Each entry in the LDT and GDT consists of an 8-byte
segment descriptor with detailed information about a
particular segment, including the base location and limit of
that segment.

IA-32 Segmentation
 The logical address is a pair (selector, offset), where the
selector is a 16-bit number:
 s designates the segment number, g indicates whether the

segment is in the GDT or LDT, and p deals with protection.
 The offset is a 32-bit number specifying the location of the
byte within the segment in question.
 The machine has six segment registers, allowing six segments
to be addressed at any one time by a process.
 It also has six 8-byte microprogram registers to hold the
corresponding descriptors from either the LDT or the GDT.
 This cache lets the Pentium avoid having to read the descriptor
from memory for every memory reference.

Intel IA-32 Segmentation
 The linear address on the IA-32 is 32 bits long
 The segment register points to the appropriate entry in the LDT
or GDT.
 The base and limit information about the segment in question is
used to generate a linear address.
 First, the limit is used to check for address validity.
 If the address is not valid, a memory fault is generated, resulting
in a trap to the operating system.
 If it is valid, then the value of the offset is added to the value of
the base, resulting in a 32-bit linear address.

Logical to Physical Address Translation in IA-32
 The IA-32 architecture allows a page size of either 4 KB or 4 MB.

 For 4-KB pages, IA-32 uses a two-level paging scheme in which
the division of the 32-bit linear address is as follows:
 The 10 high-order bits reference an entry in the outermost page

table, called the page directory.
 The CR3 register points to the page directory for the current
process.
 The page directory entry points to an inner page table that is
indexed by the contents of the innermost 10 bits in the linear
address.
 Finally, the low-order bits 0–11 refer to the offset in the 4-KB
page pointed to in the page table.

Intel IA-32 Paging Architecture
 One entry in the page directory is the Page_Size flag, which if
set, indicates that the size of the page frame is 4 MB and not
the standard 4 KB.
 If this flag is set, the page directory points directly to the 4-MB
page frame, bypassing the inner page table; and
 the 22 low-order bits in the linear address refer to the offset in
the 4-MB page frame.

Intel IA-32 Paging Architecture
 To improve the efficiency of physical memory use, IA-32 page
tables can be swapped to disk.
 In this case, an invalid bit is used in the page directory entry to
indicate whether the table to which the entry is pointing is in
memory or on disk.
 If the table is on disk, the operating system can use the other
31 bits to specify the disk location of the table.
 The table can then be brought into memory on demand.

Intel IA-32 Page Address Extensions
 32-bit address limits of 4GB, led Intel to create page address extension
(PAE), allowing 32-bit processors to access more than 4GB of physical
address space
 Paging went to a 3-level scheme
 Top two bits refer to a page directory pointer table
 Page-directory and page-table entries increased from 32-bits to 64-bits
in size, which allowed the base address of page tables and page frames
to extend from 20 to 24 bits
 Net effect is increasing address space to 36 bits – 64GB of physical
memory; operating system support is required to use PAE

Intel x86-64
 Current generation Intel x86 architecture
 64 bits address space yields an astonishing 264 bytes of
addressable memory > 16 quintillion (16 exabytes)
 In practice only implement 48 bit addressing
 Page sizes of 4 KB, 2 MB, 1 GB
 Four levels of paging hierarchy
 Can also use PAE so virtual addresses are 48 bits and
physical addresses are 52 bits

64-bit ARMv8 Architecture
 The ARMv8 has three different translation granules: 4 KB, 16 KB,
and 64 KB.
 Each translation granule provides different page sizes, as well
as larger sections of contiguous memory, known as regions.
Translation Granule Page Size Region Size
Size
4 KB 4 KB 2 MB, 1 GB
16 KB 16 KB 32 MB
64 KB 64 KB 512 MB
 For 4-KB and 16-KB granules, up to four levels of paging may be
used, with up to three levels of paging for 64-KB granules.
 ARMv8 address structure for the 4-KB translation granule with up
to four levels of paging (Notice that only 48 bits are currently
used):

 The four-level hierarchical paging structure for the 4-KB translation
granule:
 TTBR register is the translation table base register and points to the
level 0 table for the current thread
 If all four levels are used, the offset (bits 0–11) refers to the offset
within a 4-KB page.
 Table entries for level 1 and level 2 may refer either to another table
or to a 1-GB region (level-1 table) or 2-MB region (level-2 table).
 The ARM architecture supports two levels of TLBs
 Inner level has two micro TLBs (one data, one
instruction)
 The micro TLB supports ASIDs as well
 At the outer level is single main TLB
 Address translation begins at the micro-TLB level.
 In the case of a miss, the main TLB is then
checked.
 If both TLBs yield misses, a page table walk must
be performed in hardware.

End of Chapter 9
Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne

CH 09

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 09

Uploaded by

Copyright:

Available Formats

Chapter 9: Main Memory

Operating System Concepts – 10 th Edition Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.2 Silberschatz, Galvin and Gagne

 To provide a detailed description of various

Operating System Concepts – 10 th Edition 9.3 Silberschatz, Galvin and Gagne

 Program must be brought (from disk) into memory and placed

Operating System Concepts – 10 th Edition 9.4 Silberschatz, Galvin and Gagne

Physical memory Abstraction: virtual memory

Operating System Concepts – 10 th Edition 9.5 Silberschatz, Galvin and Gagne

 Threads encapsulate concurrency

Operating System Concepts – 10 th Edition 9.7 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.8 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.9 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.10 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.11 Silberschatz, Galvin and Gagne

data1: 32dw 0x300 00000020

Operating System Concepts – 10 th Edition 9.12 Silberschatz, Galvin and Gagne

 Address binding of instructions and data to memory addresses

Operating System Concepts – 10 th Edition 9.13 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.14 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.15 Silberschatz, Galvin and Gagne

 UNIX ld does the linking portion of this (despite its name

Operating System Concepts – 10 th Edition 9.17 Silberschatz, Galvin and Gagne

Data read or write(untranslated)

Operating System Concepts – 10 th Edition 9.19 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.20 Silberschatz, Galvin and Gagne

 The concept of a logical address space that is bound to a

Operating System Concepts – 10 th Edition 9.21 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.22 Silberschatz, Galvin and Gagne

 Routine is not loaded until it is

Operating System Concepts – 10 th Edition 9.23 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.24 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.25 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.26 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.27 Silberschatz, Galvin and Gagne

 If next processes to be put on CPU is not in memory, need to

Operating System Concepts – 10 th Edition 9.28 Silberschatz, Galvin and Gagne

 Other constraints as well on swapping

Operating System Concepts – 10 th Edition 9.29 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.30 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.31 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.32 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.33 Silberschatz, Galvin and Gagne

 Instead, all inter-address space (in UNIX, inter-process)

 Models of inter-address space communication:

Operating System Concepts – 10 th Edition 9.37 Silberschatz, Galvin and Gagne

 File system (read and write files). File system is

Operating System Concepts – 10 th Edition 9.38 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.39 Silberschatz, Galvin and Gagne

 In Nachos, system call to run command is simply “exec”. But

 UNIX idea: separate notion of fork vs. exec

Operating System Concepts – 10 th Edition 9.40 Silberschatz, Galvin and Gagne

Operating System Concepts – 10 th Edition 9.41 Silberschatz, Galvin and Gagne

 Justification was to allow I/O (pipes, redirection, etc.), to be

 Nachos simply combines UNIX fork and exec into one

Operating System Concepts – 10 th Edition 9.42 Silberschatz, Galvin and Gagne

 Two approaches: strong typing and software fault isolation.

Operating System Concepts – 10 th Edition 9.43 Silberschatz, Galvin and Gagne

 Note: nothing prevents shared data from being trashed;

Operating System Concepts – 10 th Edition 9.44 Silberschatz, Galvin and Gagne

Application written in Java

Native operating system (kernel

Operating System Concepts – 10 th Edition 9.45 Silberschatz, Galvin and Gagne