Today: Efficient Translation
-
Base and bounds.
-
Segmentation.
-
Paging.
$ cat announce.txt
-
ASST2 is due Friday.
Virtual Addresses: Questions?
Translation is Control
Forcing processes to translate a reference to gain access to the underlying object provides the kernel with a great deal of control.
References can be revoked, shared, moved, altered.
Virtual v. Physical Addresses
-
The address space abstraction requires breaking the connection between a memory address and physical memory.
-
We refer to data accessed via the memory interface as using virtual addresses.
-
A physical address points to memory.
-
A virtual address points to something that acts like memory.
-
Virtual addresses have much richer semantics than physical addresses, encapsulating location, permanence and protection.
Creating Virtual Addresses
-
exec()
: creates virtual addresses using an ELF file as a blueprint. -
fork()
: copies the virtual address space of the parent process. -
sbrk()
: extends the process heap. -
mmap()
: creates a virtual address region that points to a file.
Example Machine Memory Layout: System/161
-
System/161 emulates a 32-bit MIPS architecture.
-
Addresses are 32-bits wide: from 0x0 to 0xFFFFFFFF.
-
0x0–0x7FFFFFFF
: process virtual addresses. Accessible to user processes, translated by the kernel. 2 GB. -
0x80000000–0x9FFFFFFF
: kernel direct-mapped addresses. Only accessible to the kernel, translated by subtracting 0x80000000. 512 MB. Cached. -
0xA0000000–0xBFFFFFFF
: kernel direct-mapped addresses. Only accessible to the kernel. 512 MB. Uncached. -
0xC0000000–0xFFFFFFFF
: kernel virtual addresses. Only accessible to the kernel, translated by the kernel. 1 GB.
Virtual Addresses: Questions?
Efficient Translation
Goal: almost every virtual address translation should be able to proceed without kernel assistance.
-
The kernel is too slow!
-
Recall: kernel sets policy, hardware provides the mechanism.
Explicit Translation
Process: "Dear kernel, I’d like to use virtual address 0x10000. Please tell me what physical address this maps to. KTHXBAI!"
-
No! Unsafe! We can’t allow process to use physical addresses directly. All addresses must be translated.
All your addresses
Are belong to us
Implicit Translation
-
Process: "Machine! Store to address 0x10000!"
-
MMU: "Where the heck is virtual address 0x10000 supposed to map to? Kernel…help!"
-
(Exception.)
-
Kernel: Machine, virtual address 0x10000 maps to physical address 0x567400.
-
MMU: Thanks! Process: store completed!
-
Process: KTHXBAI.
Translation Example
K.I.S.S.: Base and Bound
Simplest virtual address mapping approach.
-
Assign each process a base physical address and bound.
-
Check: Virtual Address is OK if Virtual Address < bound.
-
Translate: Physical Address = Virtual Address + base
Base and Bounds: Example
Base and Bounds: Pros
-
Pro: simple! Hardware only needs to know base and bounds.
-
Pro: fast!
-
Protection: one comparison.
-
Translation: one addition.
-
Base and Bounds: Cons
-
Con: is this a good fit for our address space abstraction?
-
No! Address spaces encourage discontiguous allocation. Base and bounds allocation must be mostly contiguous otherwise we will lose memory to internal fragmentation.
-
-
Con: also significant chance of external fragmentation due to large contiguous allocations.
K.I.Simplish.S.: Segmentation
One base and bounds isn’t a good fit for the address space abstraction.
-
Yes! Multiple bases and bounds per process. We call each a segment.
-
We can assign each logical region of the address space—code, data, heap, stack—to its own segment.
-
Each can be a separate size.
-
Each can have separate permissions.
-
K.I.Simplish.S.: Segmentation
Segmentation works as follows:
-
Each segment has a start virtual address, base physical address, and bound.
-
Check: Virtual Address is OK if it inside some segment, or for some segment:
Segment Start < V.A. < Segment Start + Segment Bound. -
Translate: For the segment that contains this virtual address:
Physical Address = (V.A. - Segment Start) + Segment Base
Segmentation: Example
Segmentation fault
Core dumped
Segmentation: Pros
Have we found our ideal solution to the address translation challenge?
-
Pro: still fairly simple:
-
Protection (Segment Exists): N comparisons for N segments.
-
Translation: one addition. (Once segment located.)
-
-
Pro: can organize and protect regions of memory appropriately.
-
Pro: better fit for address spaces leading to less internal fragmentation.
Segmentation: Cons
-
Con: still requires entire segment be contiguous in memory!
-
Con: potential for external fragmentation due to segment contiguity.
So close!
But not quite.
Let’s Regroup
-
Fast mapping from any virtual byte to any physical byte.
-
Operating system cannot do this. Can hardware help?
Translation Lookaside Buffer
-
Common systems trick: when something is too slow, throw a cache at it.
-
Translation Lookaside Buffers—or TLBs—typically use content-addressable memory or CAMs to quickly search for a cached virtual-physical translation.
TLB Example
What’s the Catch?
-
CAMs are limited in size. We cannot make them arbitrarily large.
-
Segments are too large and lead to internal fragmentation.
-
Mapping individual bytes would mean that the TLB would not be able to cache many entries and performance would suffer.
-
Is there a middle ground?
Next Time
Page translation and page management.