CENG 334 Operating Systems 06 Memory Assoc Prof

CENG 334 – Operating Systems 06 - Memory Assoc. Prof. Yusuf Sahillioğlu Computer Eng. Dept, , Turkey

Memory Management 2 / 122 ü Program must be brought (from disk) into memory to run ü Main memory and registers are only storage CPU can access directly ü Register access in one CPU clock cycle (perform multiplication a * b) ü Main memory can take many cycles (read the operands from memory, or write result back to memory) ü Cache sits between main memory and CPU registers (2 -3 cycles) ü Instructions that are executed and data that is operated on ü Protection of memory required to ensure correct operation

Memory Management 3 / 122 ü Overview

Memory Management 4 / 122 ü When code is generated (or assembly program is written) we use memory addresses for variables, functions, and branching/jumping ü Those addresses can be physical or logical (=virtual) memory addreses ü Physical: discontinuous locations in main memory. ü Logical:

Memory Management 5 / 122 ü When code is generated (or assembly program is written) we use memory addresses for variables, functions, and branching/jumping ü Those addresses can be physical or logical (=virtual) memory addreses ü Physical: ü Logical: each process is given its own continuous logical memory space = own view of memory with its own addr. space Logical addresses divided into fixed-size pages.

Memory Management 6 / 122 ü Key advantage of logical addressing (= paging). ü Eliminates the issue of external fragmentation. ü Since CPU translates logical page-based addresses to physical frame-based addresses there is no need for the physical frames to be continuous

Memory Management 7 / 122 ü Physical address of a variable is 0 x 0734432. That variable has to sit there while the program is executing: no relocation. ü Logical address of a variable is 7 for my. Array[7]. Not has to sit at physical 0 x 0000007 (7 in hexadecimal).

Memory Management 8 / 122 ü Assume physical addresses in use: no problem

Memory Management 9 / 122 ü Assume physical addresses in use for 2 parallel programs: problem

Memory Management 10 / 122 ü We cannot have a multiprogramming environment. ü We cannot load a program to an arbitrary position. ü Early systems have this physical addressing idea. Thank god we don’t.

Memory Management 11 / 122 ü Logical address space concept. ü A program uses logical addresses. ü Logical address space has to be mapped somewhere in physical (main) memory.

Memory Management 12 / 122 ü Logical addresses provide ü Multiprogramming environment ü Relocatable code ü Binding: mapping logical addresses to physical addresses. ü physical. Addr = logical. Addr + base ü Logical address space is bound to a physical address space

Memory Management 13 / 122 ü An example

Memory Management 14 / 122 ü An example

Memory Management 15 / 122 ü An example ü Memory Mananagement Unit (MMU) converts logical address 28 into physical address (28 + 24 = 52 M[52]) in execution time.

Memory Management 16 / 122 ü Hardware device that at run time maps virtual (logical) to physical address ü In prev simple example we used 1 relocation register: base ü More complicated schemes around ü The user program deals with logical addresses; it never sees the real physical addresses ü Execution-time binding occurs when reference is made to location in memory ü Logical address bound to physical addresses

Memory Management 17 / 122 ü Dynamic relocation using a relocation register

Memory Management 18 / 122 ü Another memo management idea: Swapping ü Assume 10 programs loaded into memo and memory is filled up ü A process can be swapped temporarily out of memory to a backing store (disk), and then brought back into memo for continued execution ü Started if more than threshold amount of memory allocated ü Disabled again once memory demand reduced below threshold

Memory Management 19 / 122 ü Another memo management idea: Swapping

Memory Management 20 / 122 ü Contiguous allocation (continuous): allocate physical space that is equal to process’ logical address space ü Main memory usually into two partitions: ü Resident operating system, usually held in low memory with interrupt vector ü User processes then held in high memory ü Relocation registers used to protect user processes from each other, and from changing operating-system code and data ü Base register contains value of smallest physical address ü Limit register contains range of logical addresses (size of the program): each logical address must be less than the limit register ü MMU maps logical address dynamically

Memory Management 21 / 122 ü HW support for relocation and limit registers

Memory Management 22 / 122 ü Contiguous allocation ü After a while we see partitions, some of which are empty (hole).

Memory Management 23 / 122 ü Contiguous allocation ü Multiple-partition allocation ü Degree of multiprogramming limited by number of partitions ü Hole: block of available memory; holes of various size are scattered throughout memory ü When a process arrives, it is allocated memory from a hole large enough to accommodate it ü Process exiting frees its partition, adjacent free partitions combined ü Operating system maintains information about: a) allocated partitions b) free partitions (hole)

Memory Management 24 / 122 ü Contiguous allocation ü How to satsify a request of size n from a list of free holes? ü First-fit: Allocate the first hole that is big enough ü Best-fit: Allocate the smallest hole that is big enough; must search entire list, unless ordered by size ü Produces the smallest leftover hole ü Worst-fit: Allocate the largest hole; must also search entire list ü Produces the largest leftover hole

Memory Management 25 / 122 ü Fragmentation: There will be useless holes that cannot accommodate any process continuously ü External Fragmentation: external to allocated partitions you have unused space ü Total memory space exists to satisfy a request, but it is not contiguous ü Reduce external fragmentation by compaction: ü Shuffle memory contents to place all free memory together in 1 large block ü Internal Fragmentation: allocated memory may be slightly larger than requested memory; this size difference is memory internal to a partition, but not being used

Memory Management 26 / 122 ü More advanced idea for memory management: Paging ü Used for implementing virtual memory which allows a program whose size is > physical memory size to be run ü Also good for eliminating the external fragmentation ü Allows logical and physical address spaces to be noncontiguous ü High utilization of memory space

Memory Management 27 / 122 More advanced idea for memory management: Paging Divide physical memory into fixed-sized blocks called frames Size is power of 2, between 512 bytes and 16 Mbytes Divide logical memory into blocks of same size called pages Keep track of all free frames To run a program of size N pages, need to find N free frames and load program ü Set up a page table to translate logical to physical addresses ü Not a simple translation anymore: phy. Addr != log. Addr + base ü ü ü

Memory Management 28 / 122 ü More advanced idea for memory management: Paging

Memory Management 29 / 122 ü More advanced idea for memory management: Paging ü Divide physical memory into fixed-size blocks, called (page) frames. ü Page frame is a container that can hold a content which is a page.

Memory Management 30 / 122 ü More advanced idea for memory management: Paging ü Divide physical memo into fixed-size (4 K) blocks, called (page) frames. ü Frame 0 has address space from 0 to 4095, frame 1 has 4096 to 8191, . .

Memory Management 31 / 122 ü More advanced idea for memory management: Paging ü Divide logical address space into fixed-size blocks, called pages, whose size is equal to the page frame size (4 K) ü Frame 0 has address space from 0 to 4095, frame 1 has 4096 to 8191, . .

Memory Management 32 / 122 ü More advanced idea for memory management: Paging ü Divide logical address space into fixed-size blocks, called pages, whose size is equal to the page frame size (4 K) ü When program loaded into memo, allocation not have to be contiguous

Memory Management 33 / 122 ü More advanced idea for memory management: Paging ü Divide logical address space into fixed-size blocks, called pages, whose size is equal to the page frame size (4 K) ü When program loaded into memo, allocation not have to be contiguous ü Info is kept in a Page Table

Memory Management 34 / 122 ü More advanced idea for memory management: Paging ü Divide logical address space into fixed-size blocks, called pages, whose size is equal to the page frame size (4 K) ü When program loaded into memo, allocation not have to be contiguous ü Info is kept in a Page Table, determined by OS, for each process ü Conversion logical->physical done by HW (CPU)

Memory Management 35 / 122 ü ü ü More advanced idea for memory management: Paging Conversion logical->physical done by HW (CPU) Assume page. Size = 4 bytes page. Number = 1 & offset = 3 for h LA = 7; PA = ? PA = 4*6 + 3 = 27

Memory Management 36 / 122 More advanced idea for memory management: Paging Conversion logical->physical done by HW (CPU) Assume page. Size = 4 bytes _ _ //4 bit logical address First _ _ for page number Next _ _ for offset (displacement) inside page ü Logical address of h is 0 1 1 1 ü ü ü

Memory Management 37 / 122 ü ü More advanced idea for memory management: Paging Conversion logical->physical done by HW (CPU) Assume page. Size = 4 bytes LA for f = 5; PA = ? ü Logical address is 0 1 (5 in binary) ü Page number = 01 1 in decimal ü PA = 110 01 (Frame number = 6) ü Offset will not change ‘cos it is relative position; copy from LA ü 110 01 = 25 in decimal, which is the PA case for f

Memory Management 38 / 122 ü ü More advanced idea for memory management: Paging Conversion logical->physical done by HW (CPU) Assume page. Size = 4 bytes LA for l = 11; PA = ? ü Logical address is 1 0 1 1 (11 in binary) ü Page number = 10 2 in decimal ü PA = 001 11 (Frame number = 1) ü Offset will not change ‘cos it is relative position; copy from LA ü 001 11 = 7 in decimal, which is the PA case for l

Memory Management 39 / 122 ü ü More advanced idea for memory management: Paging Conversion logical->physical done by HW (CPU) Assume page. Size = 4 bytes LA for n = 13; PA = ? ü Logical address is 1 1 0 1 (13 in binary) ü Page number = 11 3 in decimal ü PA = 010 01 (Frame number = 2) ü Offset will not change ‘cos it is relative position; copy from LA ü 010 01 = 9 in decimal, which is the PA case for n

Memory Management 40 / 122 ü ü More advanced idea for memory management: Paging Conversion logical->physical done by HW (CPU) In general Address generated by CPU is divided into: ü Page number (p): used as an index into a page table which contains base address of each page in physical memory ü Page offset (d): combined with base address to define the physical memory address that is sent to the memory unit ü For given logical address space 2 m and page size 2 n

Memory Management 41 / 122 ü More advanced idea for memory management: Paging ü Conversion logical->physical done by HW (CPU) ü In general

Memory Management 42 / 122 ü More advanced idea for memory management: Paging ü Conversion logical->physical done by HW (CPU) ü Must be very fast ‘cos done for every memory reference ü At least 1 memory access to fetch the instruction ü Plus potential memory operation(s) for that instruction (LOAD) ü Setting up the page table done by SW (OS) ü When program is loaded into memo, OS knows into which frames the pages of the program are loaded

Memory Management 43 / 122 ü More advanced idea for memory management: Paging ü We will have free and used frames in memory at any time t

Memory Management 44 / 122 ü More advanced idea for memory management: Paging ü 8 -byte long program (each byte is an instruction, not a char, but anyway)

Memory Management 45 / 122 ü Implementation of Page Table ü ü Page table is kept in main memory, per process Page-table base register (PTBR) points to the page table (load with context switch) Page-table length register (PTLR) indicates size of the page table (load with cs) In this scheme every data/instruction access requires two memory accesses: 1 for the page table (‘cos table is in memory) and 1 for the data/instruction (by phy adr)

Memory Management 46 / 122 ü Implementation of Page Table ü Access to Page Table in memory (for logical physical conversion) ü Access to that physical address in memory (2 nd access)

Memory Management 47 / 122 ü Implementation of Page Table ü The two memory access problem can be solved by the use of a special fast-lookup hardware cache called associative memory or translation look-aside buffers (TLBs) ü Some TLBs store address-space identifiers (ASIDs) in each TLB entry: uniquely identifies each process to provide address-space protection for that process ü After we learn page frame, we store this association in 1 entry of TLB. ü A page has 4096 instructions so it is likely that I’ll access the same page again soon (in the next instruction); keep that page frame mapping in the cache. ü Without ASIDs you have to flush (erase) TLB at every context switch (0 17 of P 1 may not work for P 2). ü TLBs typically small (64 to 1, 024 entries)

Memory Management 48 / 122 ü TLB associative memory ü Associative memory: parallel search ü Address translation (p, d) ü If p is in associative register, get frame # out ü Otherwise get frame # from page table in memory

Memory Management 49 / 122 ü Paging HW with TLB

Memory Management 50 / 122 ü Effective memory access time w/ Paging HW with TLB ü Associative Lookup = e time unit //e = epsilon ü Assume memory access (cycle) time is 1 msec (>> e) ü Hit ratio = alpha ü Hit ratio: percentage of times that a page number is found in the TLB ü Effective Access Time (EAT) EAT = HIT + MISS = (1 + e)alpha + (2 + e)(1 – alpha) = 2 + e – alpha msecs //e << alpha so ignore it

Memory Management 51 / 122 ü Memory protection with paging scheme ü Memory protection implemented by associating protection bit with each frame ü Valid-invalid bit attached to each entry in the page table: ü “valid” indicates that the associated page is in the process’ logical address space, and is thus a legal page ü “invalid” indicates that the page is not in the process’ logical address space

Memory Management 52 / 122 ü Memory protection with paging scheme

Memory Management 53 / 122 ü Shared pages ü Shared code ü One copy of code shared among processes (e. g. , text editor program is run 3 times) ü Similar to multiple threads sharing the same process space ü Also useful for interprocess communication if sharing of read-write pages is allowed ü Private code and data ü Each process keeps a separate copy of the code and data ü The pages for the private code and data can appear anywhere in the logical address space

Memory Management 54 / 122 ü Shared pages

Memory Management 55 / 122 ü Structure of the page table is important ü 1 D page table can grow to a large size if u have a large address space ü 4 GB of logical memory (32 bit systems may have 232 =4 GB spce) ü Each page is 4 KB ü Then you have 4 GB / 4 KB = ~1 M (million) pages ü 1 M entries needed in a 1 D page table ü Each entry 4 bytes 4 MB page table per process; too large!

Memory Management 56 / 122 ü Solutions to 1 D page table problem ü Break up the logical address space into multiple page tables ü Hierarchical paging ü Hashed page tables ü Inverted page tables

Memory Management 57 / 122 ü Hierarchical page tables ü Break up the logical address space into multiple page tables ü Some portion of the logical address space will be mapped by some page table, some portion by another page tables, and so on ü This idea replaces the Single page table responsible for mapping the whole logical address space ü You usually use a small portion of your logical addr space need small page tables to map those portions. ü Unused portion stored on disk (brought to memo when necessary) ü A simple technique is a two-level page table

Memory Management 58 / 122 ü Hierarchical page tables ü Two-level page table scheme (2 D): page the page table level 1 level 2

Memory Management 59 / 122 ü If only a small portion of the logical address space from the beginning is used (common case), it may be enough just to have circled pg table page table level 1 level 2

Memory Management 60 / 122 ü Hierarchical page tables ü Two-level page table scheme (2 D): page the page table ü Logical address on 32 -bit machine with 1 K page size: page number page offset p 1 p 2 d 12 10 10 ü d=10 bits page size 2^10 = 1 K (each page stores 1 K data) ü p 2 = 10 bits second-level page table can have at most 1 K entries ü p 1 = 12 bits first-level page table can have at most 4 K entries ü p 1 is an index to outer page table ü p 2 is an index to second-level page table ü d is the offset in the page and in the frame

Memory Management 61 / 122 ü Hierarchical page tables ü Two-level page table scheme (2 D): page the page table ü From outer page table (idx: p 1), get the address of the 2 nd level page table. ü From 2 nd level page table (idx: p 2), get the page frame number in PA. ü From page frame in physical memo (idx: d), get the desired content.

Memory Management 62 / 122 ü ü ü Hierarchical page tables Two-level page table scheme (2 D): page the page table Benefit: reduce page table space needed for a program. Logical address length = 32 bits Page size = 4 K (2^12 = 4096) Logical address division: 10, 12 ü ü ü Program has 4 GB (2^32) address space But only uses bottom and top portions (20 MB) Don’t need a page table for the unused part Need only 1 top-level page table Need ? ? second-level page tables

Memory Management 63 / 122 ü Hierarchical page tables ü Two-level page table scheme (2 D): page the page table ü 2 nd-level page table has 210 entries ü Each entry can map a page of 4 K size ü 210 * 212 = 222 = 4 MB of logical address space can be mapped by a single 2 nd-level page table! Use this fact to find the answer for the prev slide. .

Memory Management 64 / 122 ü Hierarchical page tables ü Two-level page table scheme (2 D): page the page table ü Each 4 MB can be mapped by 1 2 nd-level page table need 20/4=5!!!!

Memory Management 65 / 122 ü Hierarchical page tables ü Two-level page table scheme (2 D): page the page table ü Benefit: using whole address space (4 MB per process) of 1 D case reduces to only 24 KB per process using 2 -level page table scheme. ü Assume each entry (in both top-level and 2 nd-level tables) 4 bytes.

Memory Management 66 / 122 ü ü Hierarchical page tables Three-level page table scheme (3 D) for 64 bit logical address space. Same idea but have 2 outer pages now. Every process has to have outer page table in memory: 242 too big. ü 232 still huge for top-level page table (4 GB per process).

Memory Management 67 / 122 ü Hashed page tables ü Solves the huge top-level page table problem of hierarchial page tables ü Arises after exceeding a threshold address spacing length Reduce large p into a number in, say, [0, 1 K]

Virtual Memory 68 / 122 ü Utilize memory management techniques to implement Virtual Memory ü Again separation of the logical memory and physical memory ü Virtual memory size can be much bigger than the physical memory ü Idea ü Just bring a small portion of the program into memory initially ü Bring the rest whenever that part is needed (unbring unused part) ü Initially bring the part that includes the main() ü Then jump to a long function and bring it ü Benefit ü Execute more programs in parallel ‘cos each needs less storage in physical memory ü Logical adr spc can be much larger (264) than physicl memo (1 GB)

Virtual Memory 69 / 122 ü Virtual memory that is larger than physical memory

Virtual Memory 70 / 122 ü Typical virtual address space layout ü Compiler sets this up ü It places the code/instructions ü Then data (global variables) ü Then heap section to allocate storage for pointer, e. g. malloc returns space to you from heap section (then you can write/read something to/from there) ü Then run-time stack for called functions Function A calls B, which calls C, . . stack grows with fnctn parameters, local vars, return addresses

Virtual Memory 71 / 122 ü Virtual memory can be implemented in the following way ü Demand Paging ü Bring pages into memory when they are used, i. e. , allocate memo for pages when they are used

Virtual Memory 72 / 122 ü ü ü Demand Paging: bring a page into memory only when it is needed Less I/O needed, no unnecessary I/O Less memory needed Faster response More users (each user program needs less space in physical memo) ü Page is needed reference to it ü invalid reference abort (32 bit 4 GB log add space may have unused portions) ü not-in-memory bring to memory (in used portion but not in memory yet) ü Lazy swapper: never swap a page into memory unless page’ll be needed ü Swapper that deals with pages is a pager

Virtual Memory 73 / 122 ü Valid-invalid bit: who is currently in memory? ü Initially all invalid: i ü Page[2] in memory but Page[n-1] is not ü During address translation, if bit is i page fault

Virtual Memory 74 / 122 ü Page table when some pages not in main memory Instructions in Page[0] may be using an operand stored in Page[4], which makes a page fault! suspend the program and bring it in. schedule another all pages in disk all the time (must fit otherwise can’t run)

Virtual Memory 75 / 122 ü Page fault: not being able to find a page in memory ü When triggered? ü While CPU is executing an instruction (w/ a memo operand/address at a different page not in physical memo) ü While CPU is fetching an instruction (the page containing the next instruction to execute not in main/physical memory) ü Handling? ü Get an empty frame to load the new page into ü Load the page to that empty frame (disk I/O) ü Reset page table (new index, validation bit) ü Restart the instruction that caused the page fault

Virtual Memory 76 / 122 ü Handling a page fault

Virtual Memory 77 / 122 ü Performance of demand paging ü Page fault rate 0 <= p <= 1 ü p = 0 means no page fault ü p = 1 means every reference is a page fault (page not in memo) ü Effective Access Time to Memory: EAT ü EAT = (1 -p) memory. Access + p(page. Fault. Overhead + swap page out + swap page in + restart. Overhead)

Virtual Memory 78 / 122 ü Performance of demand paging

Virtual Memory 79 / 122 ü COW: Copy-on-Write ü Just another benefit of Virtual Memory ü Easy/fast process creation ü Used during process creation (fork()) for fast child creation

Virtual Memory 80 / 122 ü COW: Copy-on-Write ü After fork() ü Child has its own address space that’s duplicated from the parent ü Child has its own memory whose content is initially same as parent ü Since they’re the same, initially we can have the child share the pages of the parent ü Maybe the child will do exec() and replace the memory; so you copied in vain ü No need to copy everything as long as child & parent are just reading those pages ü Do copying when 1 of the processes modify/write

Virtual Memory 81 / 122 ü COW: Copy-on-Write ü Before Process 1 modifies Page C Parent Child

Virtual Memory 82 / 122 ü COW: Copy-on-Write ü After Process 1 modifies Page C

Virtual Memory 83 / 122 ü Page replacement: what happens if there is no free frame to put the new page in? ü Find some not-in-use page in memory and swap it out ü Which page to remove? ü An algorithm which results in min # of page faults is preferrable ü With page replacement same page may be brought into mem 1+ times

Virtual Memory 84 / 122 ü Prevent over-allocation by 1 process by giving each process a fixed # frames to play with ü Modify page-fault service routine to include page-replacement over those frames ü Only modified pages are written back to disk (I/O) while being removed/replaced ü Attach a modify (dirty) bit to each page in memory to do this, i. e. , to reduce the overhead of page transfers ü Separation b/w logical and physical memo achieved w/ page replacmnt ü Compiler writers or assembly coders can now use a large virtual memory on a smaller physical memory

Virtual Memory 85 / 122 ü Need for page replacement

Virtual Memory 86 / 122 ü Basic page replacement steps performed by OS ü OS finds the location of the desired page on disk ü Find a free frame ü If there is one, use it ü If there is none, use a page replacement policy to select a victim frame; if the victim is modified, write it back to disk ü See policies at Onur hoca’s cool paging. js demo ü Optimum ü FIFO ü Second chance ü Least recently used (LRU) ü Bring the desired page into the free frame; update page table ü Restart the process at the instruction that caused the page fault

Virtual Memory 87 / 122 ü Basic page replacement

Virtual Memory 88 / 122 ü Expect less # of page faults as # frames increases

Virtual Memory 89 / 122 ü Page replacement policy: FIFO ü Better policies prevent such anomalies.

Virtual Memory 90 / 122 ü FIFO Illustrating Belady’s Anomaly

Virtual Memory 91 / 122 ü Other page replacement algorithms to know ü Optimal ü FIFO ü Second chance ü Least recently used (LRU) ü See Onur hoca’s demo: paging. js

Virtual Memory 92 / 122 ü Other page replacement algorithms to know ü Optimal algo: victim page is the one that will not be used for the longest time ü This alg provides the min # of page faults; no other can do that ü Requires future guessing Used for comparison of practical algos

Virtual Memory 93 / 122 ü Other page replacement algorithms to know ü Optimal algo: victim page is the one that will not be used for the longest time ü This alg provides the min # of page faults; no other can do that ü Requires future guessing Used for comparison of practical algos

Virtual Memory 94 / 122 ü Other page replacement algorithms to know ü Least recently used algo: victim page is the one that is used least recently ü Heavily used in practice. No future guessing; look to the past

Virtual Memory 95 / 122 ü Other page replacement algorithms to know ü Least recently used algo: victim page is the one that is used least recently ü Heavily used in practice. No future guessing; look to the past ü When does LRU reduce to FIFO?

Virtual Memory 96 / 122 ü Other page replacement algorithms to know ü Least recently used implementation ü Counter: every page entry has a counter; every time page is referenced copy the clock (incrementing value) into the counter ü When replacement needed, pick the one w/ min counter value ü Additional access to clock hardware

Virtual Memory 97 / 122 ü Other page replacement algorithms to know ü Least recently used implementation ü Stack: not the usual stack; more like a double-ended queue ü Move the referenced page to the top ü When replacement needed, pick the one from the bottom

Virtual Memory 98 / 122 ü Other page replacement algorithms to know ü Least recently used implementation ü Stack: with every memory reference you make more references to setup the pointers of stack, which slows down the system

Virtual Memory 99 / 122 ü Other page replacement algorithms to know ü Both Counter and Stack implementations are exact LRU solutions but inefficient ü An LRU approximation algo: reference bit ü With each page associate a bit, initially 0 (not referenced/used) ü Can be stored in page table, for example ü When page referenced, bit set to 1 ü Replace the one which is 0 ü There may be multiple 0 s so we don’t know which is the least recent ü We only know those 0 -pages are not referenced during the last clock interval ü Reference bits are cleared (0) periodically with every clock interrupt

Virtual Memory 100 / 122 ü Other page replacement algorithms to know ü Both Counter and Stack implementations are exact LRU solutions but inefficient ü Another LRU approximation algo: second-chance (clock) ü Combination of FIFO and Reference-bit algos ü R=1 initially ü To R=1 pages, give a second chance by making R=0 and moving them to tail. Reasonable ‘cos R=1 means recently used

Virtual Memory 101 / 122 ü Other page replacement algorithms to know ü Practice this (do also with second-chance (=clock) bits)

Virtual Memory 102 / 122 ü Other page replacement algorithms to know ü Counting algorithms ü Keep a counter of the # of references made to each page ü LFU: replaces page w/ the smallest count (least frequently usd) ü MFU: ? Why do I do this ?

Virtual Memory 103 / 122 ü Other page replacement algorithms to know ü Counting algorithms ü Keep a counter of the # of references made to each page ü LFU: replaces page w/ the smallest count (least frequently usd) ü MFU: based on the argument that the page with the smallest count was probably just brought in and has yet to be used

Virtual Memory 104 / 122 ü Allocation of frames ü So far we learnt which page to remove/replace in case of a page fault ü Now learn how many frames should we allocate to a process ü If the process doesn’t have enough pages in memory then page fault rate is high, which leads to ü Low CPU utilization (more I/O to retrieve pages from disk) ü OS thinks that it needs to increase the degree of multiprogramming (‘cos CPU seems to be underutilized) ü Another process added to the sys, which makes it even worse

Virtual Memory 105 / 122 ü Allocation of frames ü So far we learnt which page to remove/replace in case of a page fault ü Now learn how many frames should we allocate to a process ü Equal allocation: if 100 frames and 5 processes, give each 20 frames ü Proportional alloc: based on the size of the process

Virtual Memory 106 / 122 ü Allocation of frames ü So far we learnt which page to remove/replace in case of a page fault ü Now learn how many frames should we allocate to a process ü Equal allocation: if 100 frames and 5 processes, give each 20 frames ü Priority alloc: use proportional alloc using priorities rather than size

Virtual Memory 107 / 122 ü Allocation of frames ü So far we learnt which page to remove/replace in case of a page fault ü Now learn how many frames should we allocate to a process ü If the process doesn’t have enough pages in memory then page fault rate is high, which leads to ü Low CPU utilization (more I/O to retrieve pages from disk) ü OS thinks that it needs to increase the degree of multiprogramming (‘cos CPU seems to be underutilized) ü Another process added to the sys, which makes it even worse ü Thrashing: system is busy doing I/O (swapping pages in and out) ü A system that is thrashing can be perceived as either a very slow system or one that has come to a halt

Virtual Memory 108 / 122 ü Allocation of frames ü So far we learnt which page to remove/replace in case of a page fault ü Now learn how many frames should we allocate to a process ü If the process doesn’t have enough pages in memory then page fault rate is high, which leads to ü Low CPU utilization (more I/O to retrieve pages from disk) ü OS thinks that it needs to increase the degree of multiprogramming (‘cos CPU seems to be underutilized) ü Another process added to the sys, which makes it even worse ü Thrashing: system is busy doing I/O (swapping pages in and out) ü usually because memory or other resources have become exhausted or too limited to perform needed operations ü e. g. , excessive paging operations are taking place

Virtual Memory 109 / 122 ü Thrashing ü Initially 1 process utilizes half of the CPU (half I/O) ü As # processes increase, utilization increases as 1+ of them needs CPU ü After a while, not enough frames in memory causes page faults

Virtual Memory 110 / 122 ü To prevent thrashing, use demand paging: don’t bring the whole program into memory at once. Just bring the needed pages. ü This works ‘cos we have locality in program execution ü Some set of instructions (loops) executed repeatedly ü Pages storing those instructions heavily accessed for a while ü When does thrashing occur? ü SUM size-of-locality > total memory size ü No thrashing: Guarantee SUM size-of-locality < total memory size

Virtual Memory 111 / 122 ü Working-set model ü An algorithm to decide how many frames to give to each process ü Can also be used as a page replacement algorithm ü Look Delta back to learn the heavily used pages: WS ü Alloc |WS| frames as those pages are likely to be used again (locality)

Virtual Memory 112 / 122 ü Working-set model ü How to use as a page replacer? ü If you have only 2 frames allocated and in those frames you have a page p 1 in WS and another page p 2 not in WS ü Remove p 2

Virtual Memory 113 / 122 ü Working-set model ü WSSi (working set of Process Pi) = total # of pages referenced in the most recent Delta (varies in time) ü if Delta too small will not encompass/cover entire locality ü if Delta too large will encompass several localities ü if Delta = INF will encompass entire program ü D = SUM WSSi = total demand frames (approximation of locality) ü if D > m Thrashing (m: total memory size) ü Policy if D > m, then suspend or swap out one of the processes

Virtual Memory 114 / 122 ü Page-Fault Frequency (PFF) scheme ü Alternative to the Working-set model for frame allocation ü Dynamically tune memory size of process based on # page faults ü Monitor page fault rate for each process (faults per sec) ü If page fault rate above threshold, give process more memory ü Should cause process to fault less ü Doesn't always work! ü Recall Belady's Anomaly ü If page fault rate below threshold, reduce memory allocaton

Virtual Memory 115 / 122 ü You can understand from fault curve where the locality starts and ends ü # page faults increases as pages (of this locality) are brought in ü When needed pages (of locality) in memory, # page faults decreases

Virtual Memory 116 / 122 ü You can understand from fault curve where the locality starts and ends

Virtual Memory 117 / 122 ü Memory-mapped files: treat file disk blocks as memory pages ü Memory-mapped file I/O allows file I/O to be treated as routine memory access by mapping a disk block to a page in memory ü A file is initially read using demand paging (map some blocks of file into pages of virtual memory). A page-sized portion of the file is read from the file system into a physical page. Subsequent reads/writes to/from the file are treated as ordinary memory accesses ü Simplifies and speeds file access by driving file I/O through memory rather than read() and write() system calls ü Also allows several processes to map the same file allowing the pages in memory to be shared

Virtual Memory 118 / 122 ü Memory-mapped files: treat file disk blocks as memory pages ü Process maps file to some portion of its logical addr space via mmap()

Virtual Memory 119 / 122 ü Memory-mapped files: treat file disk blocks as memory pages ü Shared memory can be implemented this way (no disk access at all)

Virtual Memory 120 / 122 ü Allocating kernel memory ü Allocate memory to dynamic kernel objects/structures ü Static allocation during loading/booting is easy ü So far we learnt allocating memo to processes ü Allocate frames in physical memory to the pages of the processes ü Dynamic kernel objects?

Virtual Memory 121 / 122 ü Allocating kernel memory ü Allocate memory to dynamic kernel objects/structures ü Static allocation during loading/booting is easy ü So far we learnt allocating memo to processes ü Allocate frames in physical memory to the pages of the processes ü Dynamic kernel objects? ü Creation of a process initiates a PCB structure in kernel ü Creation of a semaphore, queues of condition variables

Virtual Memory 122 / 122 ü Allocating kernel memory ü Why dynamic kernel memory allocation is a problem? ü ‘cos kernel objects are much smaller than processes’ objects ü Semaphore: 8/16 bytes ü PCB: 1200 bytes ü Much less than the page size ü Can’t give whole page to a semaphore (wasteful) ü Some frames are reserved for dynamically allocated kernel objects ü Solution ü We could use first/best-fit heap management but it causes external fragmentation ü Better techniques ü Buddy system allocator ü Slab allocator

Virtual Memory 123 / 122 ü Final issue: program structure affecting page faults. row-major order (int=4 bytes) (1 frame)