Segmentation and Paging CS 332 s20

Announcements

● Lab 3 due 9pm, email me to use late days ○ No late days on lab 4 (deadline is last day of finals) ● Lab 4 available soon (you’ll be implementing some core memory functionality) ○ Design doc due May 27 ○ Peer review due June 1 (same groups) ○ Lab due June 8 ● Week 7 quiz bumped to Monday, due 9pm May 29 (Thursday) ● Mea culpa for being behind on grading Base and Bound: Simple, Limited

● Pros: ○ Simple, fast, safe ○ Can relocate physical memory without changing ● Cons: ○ Can’t prevent process from overwriting its own code (only check exceeding bound) ○ Can’t share code/data with other processes ○ Can’t grow stack/heap as needed Segmentation: Multiple Bases and Bounds to Divide Memory Into Segments ● Segment is a contiguous region of virtual memory ● Each process has a segment table (stored in hardware) ○ Each entry in the table defines a segment ● Segment can be located anywhere in physical memory ○ Each segment has: start (base), length (bound), access permissions ● Just as with base and bound, a memory access to a segment exceeding the bound triggers an exception ○ On systems, called a segmentation fault Common theme: virtual address split into index and offset

Table value and offset concatenated to form physical address 00 01 Maximum segment length? 10 11 212

segment local address Use Segmentation to Avoid Unnecessary Copying for fork: Copy-on-Write ● UNIX fork ○ Makes a complete copy of a process ○ If child never uses parent’s memory (e.g., just calls exec), a lot of unnecessary copying ● Segments allow a more efficient implementation ○ Copy segment table into child ○ Mark parent and child segments read-only ○ Start child process; return to parent ○ If child or parent writes to a segment (ex: stack, heap) ■ into kernel ■ Make a copy of the segment, change permissions, and resume Segmentation Facilitates Sharing

● Same base, bound, same/different access permissions ● For example, two instances of the same program sharing a Use Segmentation to Efficiently Manage Dynamically Allocated Memory: Zero-on-Reference ● Need to zero out contents of memory before allocation ○ Avoid accidentally leaking information! ○ But only want to bother if memory will actually be used ● How much physical memory is needed for the stack or heap? ○ Only what is currently in use (could be anywhere from KBs to GBs) ○ Reserve larger space, but only zero the first few KB, set bound to zeroed portion ● When program uses memory beyond end of stack or expands the heap ○ Segmentation fault into OS kernel ○ Kernel allocates some memory (extends bound) ○ Zeros the memory ○ Modifies the segment table ○ Resumes the process Segmentation: Big Improvement Over Simple Translation, Introduces Complexity ● Pros? ○ Can share code/data segments between processes ○ Can protect code segment from being overwritten ○ Can transparently grow stack/heap as needed ○ Can detect if need to copy-on-write ● Cons? ○ Complex ■ Need to find chunk of a particular size (e.g., some programs have small , some large) ○ May need to rearrange memory from time to time to make room for new segment or growing segment ■ Compacting free memory can create a lot of processor overhead ■ External fragmentation: wasted space between chunks Paging: Divide Memory Into Fixed-Size Pages

● Manage physical memory in fixed size units, or pages ● Finding a free page is easy ○ Bitmap allocation: 0011111100000001100 ○ Each bit represents one physical page frame, indicates free or allocated ■ Bitmaps also used in file systems to represent free disk blocks (also fixed-size units) ● Each process has its own ○ Stored in physical memory ● Hardware registers ○ Pointer to page table start ○ Page table length Program Memory May Be Scattered Throughout Physical Memory

● Each process sees its virtual address space as a neatly ordered deck of cards ● Physical memory is all the decks from all the processes shuffled together Virtual Address Used to Look Up Physical Address ● Again, part of the virtual address is an index, and part is an offset ○ Since offset is lower-order bits, specifies location within contiguous virtual page table entry page or physical frame (PTE) ● Page table contains access permissions like segment table Virtual Page Number Frame Number 0 0

1 1

2 2

3 3

4

5

6

7 Paging and Copy on Write

● Can we share memory between processes? ○ Set entries in both page tables to point to same page frames ○ Need core map of page frames to track which processes are pointing to which page frames (e.g., reference count) ● UNIX fork with copy on write ○ Copy page table of parent into child process ○ Mark all pages (in new and old page tables) as read-only ○ Trap into kernel on write (in child or parent) ○ Copy page ○ Mark both as writeable ○ Resume execution Get a Head Start: Demand Paging

● Can I start running a program before its code is in physical memory? ● Set all page table entries to invalid ● When a page is referenced for first time, kernel trap ● Kernel brings page in from disk ○ Page in on demand ● Resume execution ● Remaining pages can be transferred in the background while program is running Paging: Simplifies Physical Memory Management, Introduces Other Overhead ● Pros: ○ Fixed-size pages avoid external fragmentation (can always use free memory) ○ Finding a free page is easy, no need to rearrange to make room ○ Flexible, enables sparse address spaces ● Cons: ○ Page table is in memory, so every memory access requires an extra memory access to first retrieve the page table entry ○ What if virtual address space is large? ■ Need a page table entry for each virtual page ■ 32-bits, 4KB pages => 500K page table entries ■ 64-bits => 4 quadrillion page table entries ○ Reduce page table size with larger pages? ■ Internal fragmentation: if we don’t need all of the space inside a fixed size chunk Reading: Introduction to Paging OSTEP Chapter 18 (p. 197–208) Provides a concrete introduction to paging with examples