Carnegie Mellon Introduction to Computer Systems 15-213/18-243, spring 2009 16 th Lecture, Mar. 17 th Instructors: Gregory Kesden and Markus Püschel.

Carnegie Mellon Introduction to Computer Systems 15-213/18-243, spring 2009 16 th Lecture, Mar. 17 th Instructors: Gregory Kesden and Markus Püschel

Carnegie Mellon Signals Kernel → Process Process → Process (using kill ) 32 types of signals Sent by updating bit in pending vector You can write your own signal handlers IDNameDefault ActionCorresponding Event 2SIGINTTerminateInterrupt (e.g., ctl-c from keyboard) 9SIGKILLTerminateKill program (cannot override or ignore) 11SIGSEGVTerminate & DumpSegmentation violation 14SIGALRMTerminateTimer signal 17SIGCHLDIgnoreChild stopped or terminated

Carnegie Mellon Signal Handlers as Concurrent Flows Signal delivered Signal received Process AProcess B user code (main) kernel code user code (main) kernel code user code (handler) context switch kernel code user code (main) I curr I next

Carnegie Mellon Today More on signals Long jumps Virtual memory (VM)  Overview and motivation  VM as tool for caching  VM as tool for memory management  VM as tool for memory protection  Address translation

Carnegie Mellon Sending Signals from the Keyboard Typing ctrl-c (ctrl-z) sends a SIGINT (SIGTSTP) to every job in the foreground process group.  SIGINT – default action is to terminate each process  SIGTSTP – default action is to stop (suspend) each process Fore- ground job Back- ground job #1 Back- ground job #2 Shell Child pid=10 pgid=10 Foreground process group 20 Background process group 32 Background process group 40 pid=20 pgid=20 pid=32 pgid=32 pid=40 pgid=40 pid=21 pgid=20 pid=22 pgid=20

Carnegie Mellon Example of ctrl-c and ctrl-z bluefish>./forks 17 Child: pid=28108 pgrp=28107 Parent: pid=28107 pgrp=28107 Suspended bluefish> ps w PID TTY STAT TIME COMMAND 27699 pts/8 Ss 0:00 -tcsh 28107 pts/8 T 0:01./forks 17 28108 pts/8 T 0:01./forks 17 28109 pts/8 R+ 0:00 ps w bluefish> fg./forks 17 bluefish> ps w PID TTY STAT TIME COMMAND 27699 pts/8 Ss 0:00 -tcsh 28110 pts/8 R+ 0:00 ps w STAT (process state) Legend: First letter: S: sleeping T: stopped R: running Second letter: s: session leader +: foreground proc group See “man ps” for more details

Carnegie Mellon Signal Handler Funkiness Pending signals are not queued  For each signal type, just have single bit indicating whether or not signal is pending  Even if multiple processes have sent this signal int ccount = 0; void child_handler(int sig) { int child_status; pid_t pid = wait(&child_status); ccount--; printf("Received signal %d from process %d\n", sig, pid); } void fork14() { pid_t pid[N]; int i, child_status; ccount = N; signal(SIGCHLD, child_handler); for (i = 0; i < N; i++) if ((pid[i] = fork()) == 0) { sleep(1); /* deschedule child */ exit(0); /* Child: Exit */ } while (ccount > 0) pause(); /* Suspend until signal occurs */ }

Carnegie Mellon Living With Nonqueuing Signals Must check for all terminated jobs  Typically loop with wait void child_handler2(int sig) { int child_status; pid_t pid; while ((pid = waitpid(-1, &child_status, WNOHANG)) > 0) { ccount--; printf("Received signal %d from process %d\n", sig, pid); } void fork15() {... signal(SIGCHLD, child_handler2);... }

Carnegie Mellon Signal Handler Funkiness (Cont.) Signal arrival during long system calls (say a read ) Signal handler interrupts read() call  Linux: upon return from signal handler, the read() call is restarted automatically  Some other flavors of Unix can cause the read() call to fail with an EINTER error number ( errno ) in this case, the application program can restart the slow system call Subtle differences like these complicate the writing of portable code that uses signals

Carnegie Mellon A Program That Reacts to Externally Generated Events (Ctrl-c) #include void handler(int sig) { printf("You think hitting ctrl-c will stop the bomb?\n"); sleep(2); printf("Well..."); fflush(stdout); sleep(1); printf("OK\n"); exit(0); } main() { signal(SIGINT, handler); /* installs ctrl-c handler */ while(1) { }

Carnegie Mellon A Program That Reacts to Internally Generated Events #include int beeps = 0; /* SIGALRM handler */ void handler(int sig) { printf("BEEP\n"); fflush(stdout); if (++beeps < 5) alarm(1); else { printf("BOOM!\n"); exit(0); } linux> a.out main() { signal(SIGALRM, handler); alarm(1); /* send SIGALRM to process in 1 second */ while (1) { /* handler returns here */ }

Carnegie Mellon A Program That Reacts to Internally Generated Events #include int beeps = 0; /* SIGALRM handler */ void handler(int sig) { printf("BEEP\n"); fflush(stdout); if (++beeps < 5) alarm(1); else { printf("BOOM!\n"); exit(0); } main() { signal(SIGALRM, handler); alarm(1); /* send SIGALRM to process in 1 second */ while (1) { /* handler returns here */ } linux> a.out BEEP BOOM! bass>

Carnegie Mellon Summary Signals provide process-level exception handling  Can generate from user programs  Can define effect by declaring signal handler Some caveats  Very high overhead  >10,000 clock cycles  Only use for exceptional conditions  Don’t have queues  Just one bit for each pending signal type

Carnegie Mellon Nonlocal Jumps: setjmp/longjmp Powerful (but dangerous) user-level mechanism for transferring control to an arbitrary location  Controlled to way to break the procedure call / return discipline  Useful for error recovery and signal handling int setjmp(jmp_buf buf)  Must be called before longjmp  Identifies a return site for a subsequent longjmp  Called once, returns one or more times Implementation:  Remember where you are by storing the current register context, stack pointer, and PC value in jmp_buf  Return 0

Carnegie Mellon setjmp/longjmp (cont) void longjmp(jmp_buf buf, int i)  Meaning:  return from the setjmp remembered by jump buffer buf again...  … this time returning i instead of 0  Called after setjmp  Called once, but never returns longjmp Implementation:  Restore register context (stack pointer, base pointer, PC value) from jump buffer buf  Set %eax (the return value) to i  Jump to the location indicated by the PC stored in jump buf buf

Carnegie Mellon setjmp / longjmp Example #include jmp_buf buf; main() { if (setjmp(buf) != 0) { printf("back in main due to an error\n"); else printf("first time through\n"); p1(); /* p1 calls p2, which calls p3 */ }... p3() { if (error) longjmp(buf, 1) }

Carnegie Mellon Limitations of Nonlocal Jumps Works within stack discipline  Can only long jump to environment of function that has been called but not yet completed jmp_buf env; P1() { if (setjmp(buf)) { /* long jump to here */ } else { P2(); } P2() {... P2();... P3(); } P3() { longjmp(buf, 1); } P1 P2 P3 buf P1 Before longjmpAfter longjmp

Carnegie Mellon Limitations of Long Jumps (cont.) Works within stack discipline  Can only long jump to environment of function that has been called but not yet completed jmp_buf env; P1() { P2(); P3(); } P2() { if (setjmp(buf)) { /* long jump to here */ } P3() { longjmp(buf, 1); } buf P1 P2 At setjmp P1 P3 buf At longjmp X P1 P2 P2 returns buf X

Carnegie Mellon Putting It All Together: A Program That Restarts Itself When ctrl-c ’d #include sigjmp_buf buf; void handler(int sig) { siglongjmp(buf, 1); } main() { signal(SIGINT, handler); if (!sigsetjmp(buf, 1)) printf("starting\n"); else printf("restarting\n"); while(1) { sleep(1); printf("processing...\n"); } bass> a.out Ctrl-c starting processing... restarting processing... restarting processing... Ctrl-c

Carnegie Mellon Programs refer to virtual memory addresses  movl (%ecx),%eax  Conceptually very large array of bytes  Each byte has its own address  Actually implemented with hierarchy of different memory types  System provides address space private to particular “process” Allocation: Compiler and run-time system  Where different program objects should be stored  All allocation within single virtual address space But why virtual memory? Why not physical memory? Virtual Memory (Previous Lectures) 00∙∙∙∙∙∙0 FF∙∙∙∙∙∙F

Carnegie Mellon Problem 1: How Does Everything Fit? 64-bit addresses: 16 Exabyte Physical main memory: Few Gigabytes ? And there are many processes ….

Carnegie Mellon Problem 2: Memory Management Physical main memory What goes where? stack heap.text.data … Process 1 Process 2 Process 3 … Process n x

Carnegie Mellon Problem 3: How To Protect Physical main memory Process i Process j Problem 4: How To Share? Physical main memory Process i Process j

Carnegie Mellon Solution: Level Of Indirection Each process gets its own private memory space Solves the previous problems Physical memory Virtual memory Process 1 Process n mapping

Carnegie Mellon Address Spaces Linear address space: Ordered set of contiguous non-negative integer addresses: {0, 1, 2, 3 … } Virtual address space: Set of N = 2 n virtual addresses {0, 1, 2, 3, …, N-1} Physical address space: Set of M = 2 m physical addresses {0, 1, 2, 3, …, M-1} Clean distinction between data (bytes) and their attributes (addresses) Each object can now have multiple addresses Every byte in main memory: one physical address, one (or more) virtual addresses

Carnegie Mellon A System Using Physical Addressing Used in “simple” systems like embedded microcontrollers in devices like cars, elevators, and digital picture frames 0: 1: M-1: Main memory CPU 2: 3: 4: 5: 6: 7: Physical address (PA) Data word 8:...

Carnegie Mellon A System Using Virtual Addressing Used in all modern desktops, laptops, workstations One of the great ideas in computer science MMU checks the cache 0: 1: M-1: Main memory MMU 2: 3: 4: 5: 6: 7: Physical address (PA) Data word 8:... CPU Virtual address (VA) CPU Chip

Carnegie Mellon Why Virtual Memory (VM)? Efficient use of limited main memory (RAM)  Use RAM as a cache for the parts of a virtual address space  some non-cached parts stored on disk  some (unallocated) non-cached parts stored nowhere  Keep only active areas of virtual address space in memory  transfer data back and forth as needed Simplifies memory management for programmers  Each process gets the same full, private linear address space Isolates address spaces  One process can’t interfere with another’s memory  because they operate in different address spaces  User process cannot access privileged information  different sections of address spaces have different permissions

Carnegie Mellon VM as a Tool for Caching Virtual memory: array of N = 2 n contiguous bytes  think of the array (allocated part) as being stored on disk Physical main memory (DRAM) = cache for allocated virtual memory Blocks are called pages; size = 2 p PP 2 m-p -1 Physical memory Empty Uncached VP 0 VP 1 VP 2 n-p -1 Virtual memory Unallocated Cached Uncached Unallocated Cached Uncached PP 0 PP 1 Empty Cached 0 2 n -1 2 m -1 0 Virtual pages (VP's) stored on disk Physical pages (PP's) cached in DRAM Disk

Carnegie Mellon Memory Hierarchy: Core 2 Duo Disk Main Memory L2 unified cache L1 I-cache L1 D-cache CPUReg 2 B/cycle8 B/cycle16 B/cycle1 B/30 cyclesThroughput: Latency:100 cycles14 cycles3 cyclesmillions ~4 MB 32 KB ~4 GB~500 GB Not drawn to scale L1/L2 cache: 64 B blocks Miss penalty (latency): 30x Miss penalty (latency): 10,000x

Carnegie Mellon DRAM Cache Organization DRAM cache organization driven by the enormous miss penalty  DRAM is about 10x slower than SRAM  Disk is about 10,000x slower than DRAM  For first byte, faster for next byte Consequences  Large page (block) size: typically 4-8 KB, sometimes 4 MB  Fully associative  Any VP can be placed in any PP  Requires a “large” mapping function – different from CPU caches  Highly sophisticated, expensive replacement algorithms  Too complicated and open-ended to be implemented in hardware  Write-back rather than write-through

Carnegie Mellon Address Translation: Page Tables A page table is an array of page table entries (PTEs) that maps virtual pages to physical pages. Here: 8 VPs  Per-process kernel data structure in DRAM null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 4 Virtual memory (disk) Valid 0 1 0 1 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3

Carnegie Mellon Address Translation With a Page Table Virtual page number (VPN)Virtual page offset (VPO) Physical page number (PPN)Physical page offset (PPO) Virtual address Physical address Valid Physical page number (PPN) Page table base register (PTBR) Page table Page table address for process Valid bit = 0: page not in memory (page fault)

Carnegie Mellon Page Hit Page hit: reference to VM word that is in physical memory null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 4 Virtual memory (disk) Valid 0 1 0 1 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3 Virtual address

Carnegie Mellon Page Miss Page miss: reference to VM word that is not in physical memory null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 4 Virtual memory (disk) Valid 0 1 0 1 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3 Virtual address

Carnegie Mellon Handling Page Fault Page miss causes page fault (an exception) null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 4 Virtual memory (disk) Valid 0 1 0 1 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3 Virtual address

Carnegie Mellon Handling Page Fault Page miss causes page fault (an exception) Page fault handler selects a victim to be evicted (here VP 4) null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 4 Virtual memory (disk) Valid 0 1 0 1 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3 Virtual address

Carnegie Mellon Handling Page Fault Page miss causes page fault (an exception) Page fault handler selects a victim to be evicted (here VP 4) null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 3 Virtual memory (disk) Valid 0 1 1 0 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3 Virtual address

Carnegie Mellon Handling Page Fault Page miss causes page fault (an exception) Page fault handler selects a victim to be evicted (here VP 4) Offending instruction is restarted: page hit! null Memory resident page table (DRAM) Physical memory (DRAM) VP 7 VP 3 Virtual memory (disk) Valid 0 1 1 0 0 1 0 1 Physical page number or disk address PTE 0 PTE 7 PP 0 VP 2 VP 1 PP 3 VP 1 VP 2 VP 4 VP 6 VP 7 VP 3 Virtual address

Carnegie Mellon Why does it work? Locality Virtual memory works because of locality At any point in time, programs tend to access a set of active virtual pages called the working set  Programs with better temporal locality will have smaller working sets If (working set size < main memory size)  Good performance for one process after compulsory misses If ( SUM(working set sizes) > main memory size )  Thrashing: Performance meltdown where pages are swapped (copied) in and out continuously

Carnegie Mellon VM as a Tool for Memory Management Key idea: each process has its own virtual address space  It can view memory as a simple linear array  Mapping function scatters addresses through physical memory  Well chosen mappings simplify memory allocation and management Virtual Address Space for Process 1: Physical Address Space (DRAM) 0 N-1 (e.g., read-only library code) Virtual Address Space for Process 2: VP 1 VP 2... 0 N-1 VP 1 VP 2... PP 2 PP 6 PP 8... 0 M-1 Address translation

Carnegie Mellon VM as a Tool for Memory Management Memory allocation  Each virtual page can be mapped to any physical page  A virtual page can be stored in different physical pages at different times Sharing code and data among processes  Map virtual pages to the same physical page (here: PP 6) Virtual Address Space for Process 1: Physical Address Space (DRAM) 0 N-1 (e.g., read-only library code) Virtual Address Space for Process 2: VP 1 VP 2... 0 N-1 VP 1 VP 2... PP 2 PP 6 PP 8... 0 M-1 Address translation

Carnegie Mellon Simplifying Linking and Loading Linking  Each program has similar virtual address space  Code, stack, and shared libraries always start at the same address Loading  execve() allocates virtual pages for.text and.data sections = creates PTEs marked as invalid  The.text and.data sections are copied, page by page, on demand by the virtual memory system Kernel virtual memory Memory-mapped region for shared libraries Run-time heap (created by malloc ) User stack (created at runtime) Unused 0 %esp (stack pointer) Memory invisible to user code brk 0xc0000000 0x08048000 0x40000000 Read/write segment (. data,. bss ) Read-only segment (.init,. text,.rodata ) Loaded from the executable file

Carnegie Mellon VM as a Tool for Memory Protection Extend PTEs with permission bits Page fault handler checks these before remapping  If violated, send process SIGSEGV (segmentation fault) Process i: AddressREADWRITE PP 6YesNo PP 4Yes PP 2Yes VP 0: VP 1: VP 2: Process j: Yes SUP No Yes AddressREADWRITE PP 9YesNo PP 6Yes PP 11Yes SUP No Yes No VP 0: VP 1: VP 2: Physical Address Space PP 2 PP 4 PP 6 PP 8 PP 9 PP 11

Carnegie Mellon Address Translation: Page Hit 1) Processor sends virtual address to MMU 2-3) MMU fetches PTE from page table in memory 4) MMU sends physical address to cache/memory 5) Cache/memory sends data word to processor MMU Cache/ Memory PA Data CPU VA CPU Chip PTEA PTE 1 2 3 4 5

Carnegie Mellon Address Translation: Page Fault 1) Processor sends virtual address to MMU 2-3) MMU fetches PTE from page table in memory 4) Valid bit is zero, so MMU triggers page fault exception 5) Handler identifies victim (and, if dirty, pages it out to disk) 6) Handler pages in new page and updates PTE in memory 7) Handler returns to original process, restarting faulting instruction MMU Cache/ Memory CPU VA CPU Chip PTEA PTE 1 2 3 4 5 Disk Page fault handler Victim page New page Exception 6 7

Carnegie Mellon Introduction to Computer Systems 15-213/18-243, spring 2009 16 th Lecture, Mar. 17 th Instructors: Gregory Kesden and Markus Püschel.

Similar presentations

Presentation on theme: "Carnegie Mellon Introduction to Computer Systems 15-213/18-243, spring 2009 16 th Lecture, Mar. 17 th Instructors: Gregory Kesden and Markus Püschel."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Carnegie Mellon Introduction to Computer Systems 15-213/18-243, spring 2009 16 th Lecture, Mar. 17 th Instructors: Gregory Kesden and Markus Püschel.

Similar presentations

Presentation on theme: "Carnegie Mellon Introduction to Computer Systems 15-213/18-243, spring 2009 16 th Lecture, Mar. 17 th Instructors: Gregory Kesden and Markus Püschel."— Presentation transcript:

Similar presentations

About project

Feedback