Click here to load reader

CS162 Operating Systems and Systems Programming Final Exam Review

  • View
    57

  • Download
    0

Embed Size (px)

DESCRIPTION

CS162 Operating Systems and Systems Programming Final Exam Review. May 6, 2013 Haoyuan Li, Neeraja Yadwadkar, Daniel Bruckner http :// inst.eecs.berkeley.edu /~cs162. Slides taken from: Mosharaf Chowdhury and Karthik Reddy. Final Exam. Friday May 17 08:00 – 11:00AM in 1 Pimentel - PowerPoint PPT Presentation

Text of CS162 Operating Systems and Systems Programming Final Exam Review

CS162 Operating Systems and Systems Programming Final Exam Review

CS162Operating Systems andSystems Programming

Final Exam ReviewMay 6, 2013Haoyuan Li, Neeraja Yadwadkar, Daniel Brucknerhttp://inst.eecs.berkeley.edu/~cs162Slides taken from: Mosharaf Chowdhury and Karthik ReddyFinal ExamFriday May 17 08:00 11:00AM in 1 Pimentel

Two double-sided handwritten pages of notes

Closed book

ComprehensiveAll lectures, discussions, projects, readings, handoutsTopicsSynchronizationPrimitives, Deadlock

Memory managementAddress translation, Caches, TLBs, Demand Paging

Distributed SystemsNaming, Security, Networking

FilesystemsDisks, Directories

Transactions

Memory Multiplexing, Address TranslationImportant Aspects of Memory MultiplexingControlled overlap:Processes should not collide in physical memoryConversely, would like the ability to share memory when desired (for communication)Protection:Prevent access to private memory of other processesDifferent pages of memory can be given special behavior (Read Only, Invisible to user programs, etc).Kernel data protected from User programsPrograms protected from themselvesTranslation: 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 addressesSide effects:Can be used to avoid overlapCan be used to give uniform view of memory to programsWhy Address Translation?Prog 1VirtualAddressSpace 1Prog 2VirtualAddressSpace 2CodeDataHeapStackCodeDataHeapStackData 2Stack 1Heap 1OS heap & StacksCode 1Stack 2Data 1Heap 2Code 2OS codeOS dataTranslation Map 1Translation Map 2Physical Address SpaceDual-Mode OperationCan an application modify its own translation maps?If it could, could get access to all of physical memoryHas to be restricted somehow

To assist with protection, hardware provides at least two modes (Dual-Mode Operation):Kernel mode (or supervisor or protected)User mode (Normal program mode)Mode set with bits in special control register only accessible in kernel-modeUserKernel: System calls, Traps, or Interrupts

Addr. Translation: Segmentation vs. PagingBase0Limit0VBase1Limit1VBase2Limit2VBase3Limit3NBase4Limit4VBase5Limit5NBase6Limit6NBase7Limit7VOffsetSeg #VirtualAddressBase2Limit2V+PhysicalAddress>ErrorPhysical AddressOffsetOffsetVirtualPage #Virtual Address:PageTablePtrpage #0page #2page #3page #4page #5V,Rpage #1V,RV,R,WV,R,WNV,R,Wpage #1V,RCheck PermAccessErrorPhysicalPage #Review: Address Segmentation 1111 1111stackheapcodedataVirtual memory viewPhysical memory viewdataheapstack0000 00000001 00000101 00000111 00000000 00000100 00001000 00001100 00001111 0000Seg #baselimit000001 000010 0000010101 000010 0000100111 00001 1000111011 00001 0000seg #offsetcode1011 0000Review: Address Segmentation 1111 1111stackheapcodedataVirtual memory viewPhysical memory viewdataheapstack0000 00000100 00001000 00001100 0000seg #offsetcodeWhat happens if stack grows beyond 1110 0000?1110 00000000 00000001 00000101 00000111 00001011 0000Seg #baselimit000001 000010 0000010101 000010 0000100111 00001 1000111011 00001 0000Review: Address Segmentation 1111 1111stackheapcodedataVirtual memory viewPhysical memory viewdataheapstack0000 00000100 00001000 00001100 00001110 0000seg #offsetcodeNo room to grow!! Buffer overflow error0000 00000001 00000101 00000111 00001110 000Seg #baselimit000001 000010 0000010101 000010 0000100111 00001 1000111011 00001 0000Review: Page Tables1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 00001111 0000page #offsetPhysical memory viewdatacodePTheapstack0000 00000001 00000101 0000111 0001110 000011111 1110111110 1110011101 null 11100 null 11011 null11010 null11001 null11000 null10111 null10110 null10101 null10100 null10011 null10010 1000010001 0111110000 0111001111 null01110 null 01101 null01100 null01011 01101 01010 01100 01001 0101101000 0101000111 null00110 null00101 null 00100 null 00011 0010100010 0010000001 0001100000 00010Page TableReview: Page Tables1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 0000page #offsetPhysical memory viewdatacodePTheapstack0000 00000001 00000101 0000111 0001110 000011111 1110111110 1110011101 null 11100 null 11011 null11010 null11001 null11000 null10111 null10110 null10101 null10100 null10011 null10010 1000010001 0111110000 0111001111 null01110 null 01101 null01100 null01011 01101 01010 01100 01001 0101101000 0101000111 null00110 null00101 null 00100 null 00011 0010100010 0010000001 0001100000 00010Page Table1110 0000What happens if stack grows to 1110 0000?stackReview: Page Tables1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 0000page #offsetPhysical memory viewdatacodePTheapstack11111 1110111110 1110011101 1011111100 1011011011 null11010 null11001 null11000 null10111 null10110 null10101 null10100 null10011 null10010 1000010001 0111110000 0111001111 null01110 null01101 null01100 null01011 01101 01010 01100 01001 0101101000 0101000111 null00110 null00101 null 00100 null 00011 0010100010 0010000001 0001100000 00010Page Table0000 00000001 00000101 0000111 0001110 0000Allocate new pages where room!Challenge: Table size equal to the # of pages in virtual memory!1110 0000stackReview: Two-Level Page Tables1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 0000page1 #offsetPhysical memory viewdatacodePT2PT1heapstack0000 00000001 00000101 0000111 0001110 0000page2 #111 110 null101 null100 011 null010 001 null000 11 11101 10 1110001 1011100 1011011 01101 10 0110001 0101100 0101011 00101 10 0010001 0001100 0001011 null 10 1000001 0111100 01110Page Tables(level 2)Page Table(level 1)1110 0000stackReview: Two-Level Page TablesstackheapcodedataVirtual memory view1001 0000Physical memory viewdatacodePT2PT1heapstack0000 00000001 00001000 00001110 0000111 110 null101 null100 011 null010 001 null000 11 11101 10 1110001 1011100 1011011 01101 10 0110001 0101100 0101011 00101 10 0010001 0001100 0001011 null 10 1000001 0111100 01110Page Tables(level 2)Page Table(level 1)In best case, total size of page tables number of pages used by program. But requires one additional memory access!1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 00001110 0000seg #offsetSeg #baselimit000000 00004010000 10004101110 20003111110 30004stackPhysical memory viewdatacodePT 2PT 2heapstack0000 00000001 00000101 0000111 0001110 000011 11101 10 1110001 1011100 1011011 01101 10 0110001 0101100 0101011 00101 10 0010001 0001100 0001011 null 10 1000001 0111100 01110Page Tables(level 2)Review: Segmentation & Page Tables1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 00001110 0000seg #offsetSeg #baselimit000000 00004010000 10004101110 20003111110 30004stackPhysical memory viewdatacodePT 2PT 2heapstack0000 00000001 00000101 0000111 0001110 000011 11101 10 1110001 1011100 1011011 01101 10 0110001 0101100 0101011 00101 10 0010001 0001100 0001011 null 10 1000001 0111100 01110Page Tables(level 2)Review: Segmentation & Page Tables1001 00001000 0000stackReview: Inverted Page Table1111 1111stackheapcodedataVirtual memory view0000 00000100 00001000 00001100 0000page #offsetPhysical memory viewdatacodeIPTheapstack11111 1110111110 1110011101 10111 1011010010 1000010001 01111 0111001011 01101 01010 01100 01001 010110 01010 00011 0010100010 0010000001 0001100000 00010Inverted Tablehash(virt. page #) = physical page #0000 00000001 00000101 0000111 0001110 00001110 0000Total size of page table number of pages used by program. But hash more complex.Address Translation ComparisonAdvantagesDisadvantagesSegmentationFast context switching: Segment mapping maintained by CPU External fragmentationPage Tables(single-level page)No external fragmentationLarge size: Table size ~ virtual memoryInternal fragmentationPage Tables& SegmentationNo external fragmentationTable size ~ memory used by programMultiple memory references per page access Internal fragmentationTwo-level page tablesInverted TableHash function more complexCaches, TLBsCompulsory (cold start): first reference to a blockCold fact of life: not a whole lot you can do about itNote: When running billions of instruction, Compulsory Misses are insignificantCapacity:Cache cannot contain all blocks access by the programSolution: increase cache sizeConflict (collision):Multiple memory locations mapped to same cache locationSolutions: increase cache size, or increase associativityTwo others:Coherence (Invalidation): other process (e.g., I/O) updates memory Policy: Due to non-optimal replacement policyReview: Sources of Cache Misses(Capacity miss) That is the cache misses are due to the fact that the cache is simply not large enough to contain all the blocks that are accessed by the program.The solution to reduce the Capacity miss rate is simple: increase the cache size.Here is a summary of other types of cache miss we talked about.First is the Compulsory misses. These are the misses that we cannot avoid. They are caused when we first start the program.Then we talked about the conflict misses. They are the misses that caused by multiple memory locations being mapped to the same cache location.There are two solutions to reduce conflict misses. The first one is, once again, increase the cache siz