Operating Systems Design and Implementation Chapter 04 (version - PDF document

Operating Systems Design and Implementation Chapter 04 (version January 30, 2008 ) Melanie Rieback Vrije Universiteit Amsterdam, Faculty of Sciences Dept. Computer Science Room R4.23. Tel: (020) 598 7874 E-mail: melanie@cs.vu.nl, URL: www.cs.vu.nl/ ∼ melanie/ 01 Introduction 02 Processes 03 Input/Output 04 Memory Management 05 File Systems 00 – 1 / Memory Management • Simple memory management • Swapping • Virtual memory • Page replacement • Design issues for paging systems • Segmentation • Memory management in MINIX 04 – 1 Memory Management/

Memory Management Simple Model Idea: Assume there is just a single process at a time in main memory (the MS-DOS model). Then, there is hardly any memory to be managed: 0xFFF … Device� Operating� drivers in ROM system in� ROM User� program User� program User� program Operating� Operating� system in� system in� RAM RAM 0 0 0 (a) (b) (c) 04 – 2 Memory Management/4.1 Simple Model Memory Management Multitasking Model Idea: just have more than one process in main mem- ory. It’s good for CPU utilization. 1 0.2 0.8 0.5 0.6 CPU utilization 0.4 0.8 0.2 0 0 2 4 6 8 10 Number of processes Question: what can we say about the relation memory– cpu utilization ( p is fraction spent in I/O wait)? Overall conclusion: having several processes in mem- ory simultaneously (and that have things to do), is a good idea. 04 – 3 Memory Management/4.1 Simple Model

Program Relocation (1/2) Problem: After compiling and linking programs, we don’t want to have addresses hardcoded into the bi- nary: this will only allow us to place the program at a fixed location in memory. Idea: Use relative addressing: all addresses in a bi- nary are relative to the start address after placing it in memory. Solution: get hardware support (changing addresses at load time is not really the thing to do). 04 – 4 Memory Management/4.1 Simple Model Program Relocation (2/2) 0 1400 100 2304 1500 8965 + 1400 MOVE 100,D0 base register 04 – 5 Memory Management/4.1 Simple Model

Program Protection (1/2) Problem: we can have some rather nasty problems: nasty: mov A0, #end ; Move the address of ; last instruction ; into register A0 loop: mov (A0), #0 ; Store 0 at location ; identified by A0 add A0, #1 ; Increment address ; in A0 jmp loop ; Loop forever end: ret ; Never reached 04 – 6 Memory Management/4.1 Simple Model Program Protection (2/2) Solution: make use of limit register. 0 1400 100 2304 base register limit register 1400 12000 ok ok 8965 + > > MOVE 100,D0 not ok 12000 out-of-limit signal 04 – 7 Memory Management/4.1 Simple Model

Fragmentation: Problem Problem: it may be that there are more processes available than memory can handle ⇒ swap processes between primary and secondary memory. This may lead to memory fragmentation. program P 1 P 2 P 3 P 4 P 5 size 1024 595 320 560 482 completion time 2 3 4 4 2 0 P P P 1 4 4 P 1 step 1 560 P 2 step 2 P 1024 3 P P P 2 2 5 P 4 step 3 1506 P 1619 5 P P P 3 3 3 time 1939 2048 step 1 step 2 step 3 Question: What is wrong with this example? 04 – 8 Memory Management/4.1 Simple Model Fragmentation: Solution • Move all running processes so that they are adja- cent, leaving one big chunk of free memory ( mem- ory compaction ). Not really doable. • Keep track of adjacent holes of free memory and merge them into one. Note that this is done in software. allocated memory free memory chunks allocated memory being returned time 04 – 9 Memory Management/4.1 Simple Model

� � � � � Memory Organization per Process Idea: you have to be aware of processes growing and shrinking ⇒ take this into account when allocat- ing memory. B-Stack Room for growth Room for growth B-Data B Actually in use B-Program A-Stack Room for growth Room for growth A-Data A Actually in use A-Program Operating� Operating� system system (a) (b) Question: Is it possible that we can have a dynamic allocation of memory? How should this work? How does this compare to malloc() and free() ? 04 – 10 Memory Management/4.2 Swapping MM – Bit Maps Problem: we want to keep track (in software) which part of memory is free to allocate to processes. • Divide memory into units of blocks, e.g. each block consists of 4 consecutive bytes. • Use a bitmap that indicates if a block is allocated or not. Note that each bitmap value requires only a single bit: 0 → the block is free; 1 → the block is allocated. • When k consecutive blocks need to be allocated, search for k consecutive 0’s in the bitmap. Question: Where do we store the bitmap? Note: Pretty efficient: if the block size is B bytes, we’ll need only 1 / ( 8 B ) -th of the total memory for the bitmap. Question: What’s the real disadvantage? 04 – 11 Memory Management/4.2 Swapping

MM – Linked Lists (1/2) Idea: keep track of holes by means of a linked list: Start address 5 224 496 100 50 Length 29 Next hole Start address 5 175 224 496 100 25 50 Length 29 Next hole Start address 5 175 224 496 125 25 50 Length 29 Next hole Start address 5 224 496 195 50 Length 29 Next hole Question: What’s happened here? 04 – 12 Memory Management/4.2 Swapping MM – Linked Lists (2/2) Idea: If you use linked lists you can decide on the “best” hole that you can use for allocation: • First fit – first hole big enough is used. • Next fit – keep track of last allocation; next hole big enough is used. • Best fit – choose the smallest hole that is big enough for allocation. • Worst fit – choose the largest hole that is big enough. • Quick fit – maintain lists that correspond to fre- quently occurring requests. Question: How relevant do you think all this mumbo jumbo is? 04 – 13 Memory Management/4.2 Swapping

Paged Memory Systems (1/2) Problem: So far, it is only possible to place a pro- cess into memory when there is a contiguous piece of memory available ⇒ allocation may succeed after a long time. Solution: Divide memory and the program into pages , and just check if there are enough free pages for the program. Each page has a fixed size (say 256 bytes). Needed: A mapping of physical pages (also called page frames ) to logical pages. • Assume a program is divided into 9 logical pages L 0 , ..., L 8 . • Main memory is divided into 256-byte page frames . Assume that P 6 is the first free page frame ⇒ use P 6 to store data and instructions contained in L 0 . • Use the next free page frame for L 1 , etc. 04 – 14 Memory Management/4.3 Virtual Memory Paged Memory Systems (2/2) Note: We need to do something about address trans- lation: • In the program we use a logical address, say 26251. Assume page sizes are 256 = 2 8 bytes. We ex- tract the logical page number and page offset as: 2 8 = 26251 div = 102 p log 2 8 o = 26251 mod = 139 • The page number is looked up in the page table to find the page frame number p phys . • The physical address is obtained as p phys ∗ 2 8 + o . • Bad news: we have to do a table lookup for every memory reference. • Good news: table lookups can be done very effi- ciently because we (1) can easily derive the log- ical page number, and (2) we get some support from the hardware. 04 – 15 Memory Management/4.3 Virtual Memory

Paged Systems Hardware Support (1/2) Note: Deriving the logical page number is easy: 26251 �→ 000001100110 10001011 � �� � � �� � 12 8 Hardware: implementation of the page table (as part of the Memory Management Unit . 04 – 16 Memory Management/4.3 Virtual Memory Paged Systems Hardware Support (2/2) 12 bits 8 bits 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0 1634 0 0 0 0 0 0 0 0 0 0 1 1 0 (6) 1 0 0 0 0 0 0 0 1 1 1 0 1 (29) page table 2 0 0 0 0 0 1 0 0 0 0 1 1 (67) 3 0 0 0 1 0 0 1 0 0 0 0 1 (289) register 4 0 0 1 0 1 1 0 1 0 0 1 1 (723) 5 0 1 1 1 0 1 0 1 0 1 1 1 (1879) 6 1 0 1 0 0 1 0 1 0 0 1 1 (2643) 7 1 0 1 0 0 1 0 1 0 1 0 0 (2644) 8 1 1 1 0 1 1 0 1 1 0 1 0 (3802) 0 0 0 1 0 0 1 0 0 0 0 1 1 1 1 0 1 0 0 0 12 bits 8 bits 04 – 17 Memory Management/4.3 Virtual Memory

Multilevel Page Tables Essence : Instead of having a single, huge page table in memory, we divide the page table into parts using an additional level of indirection. Second-level� page tables Page� table for� the top� 4M of� memory Top-level� page table 1023 6� Bits 10 10 12 5� PT1 PT2 Offset 4� 3� (a) 2� 1� 0 1023 6� 5� 4� To� 3� pages 2� 1� 0 (b) 04 – 18 Memory Management/4.3 Virtual Memory Lookaside Buffers Problem : If we really have to translate every address to a page frame, we’re loosing a lot of performance. Therefore, keep a number of translations separate in a translation lookaside buffer . Essence : Instead of going to the page table, we check a virtual address with all entries in the TLB in parallel . Assumption : Most programs exhibit a high degree of locality : they use just a few pages ( working set ). 04 – 19 Memory Management/4.3 Virtual Memory