Technical Women

Figure 1. Anuradha Annaswamy

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.

This MIPS architecture defines four address regions:
  • 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!"

Does this work?
  • 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

translationexample 1
translationexample 2
translationexample 3
translationexample 4
translationexample 5
translationexample 6
translationexample 7
translationexample 8
translationexample 9
translationexample 10
translationexample 11
translationexample 12
translationexample 13

K.I.S.S.: Base and Bound

Simplest virtual address mapping approach.

  1. Assign each process a base physical address and bound.

  2. Check: Virtual Address is OK if Virtual Address < bound.

  3. Translate: Physical Address = Virtual Address + base

Base and Bounds: Example

baseandbounds 1
baseandbounds 2
baseandbounds 3
baseandbounds 4
baseandbounds 5
baseandbounds 6
baseandbounds 7
baseandbounds 8
baseandbounds 9
baseandbounds 10

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.

baseandboundscon 1
baseandboundscon 2
baseandboundscon 3
baseandboundscon 4

K.I.Simplish.S.: Segmentation

One base and bounds isn’t a good fit for the address space abstraction.

But can we extend this idea?
  • 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:

  1. Each segment has a start virtual address, base physical address, and bound.

  2. Check: Virtual Address is OK if it inside some segment, or for some segment:
    Segment Start < V.A. < Segment Start + Segment Bound.

  3. Translate: For the segment that contains this virtual address:
    Physical Address = (V.A. - Segment Start) + Segment Base

Segmentation: Example

segments 1
segments 2
segments 3
segments 4
segments 5
segments 6
segments 7
segments 8
segments 9
segments 10
segments 11
segments 12
segments 13
segments 14

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

Ideally, what would we like?
  • 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

tlb 1
tlb 2
tlb 3
tlb 4

What’s the Catch?

  • CAMs are limited in size. We cannot make them arbitrarily large.

So at this point:
  • 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.