50
1 CMSC421: Principles of Operating Systems Nilanjan Banerjee Principles of Operating Systems Acknowledgments: Some of the slides are adapted from Prof. Mark Corner and Prof. Emery Berger’s OS course at Umass Amherst Assistant Professor, University of Maryland Baltimore County [email protected] http://www.csee.umbc.edu/~nilanb/teaching/ 421/

CMSC421: Principles of Operating Systems

  • Upload
    yachi

  • View
    30

  • Download
    0

Embed Size (px)

DESCRIPTION

CMSC421: Principles of Operating Systems. Nilanjan Banerjee. Assistant Professor, University of Maryland Baltimore County [email protected] http://www.csee.umbc.edu/~nilanb/teaching/421/. Principles of Operating Systems - PowerPoint PPT Presentation

Citation preview

Page 1: CMSC421: Principles of Operating Systems

1

CMSC421: Principles of Operating Systems

Nilanjan Banerjee

Principles of Operating SystemsAcknowledgments: Some of the slides are adapted from Prof. Mark Corner

and Prof. Emery Berger’s OS course at Umass Amherst

Assistant Professor, University of MarylandBaltimore [email protected]

http://www.csee.umbc.edu/~nilanb/teaching/421/

Page 2: CMSC421: Principles of Operating Systems

2

Announcements

• Project 2 progress report due one week from Nov. 9th

Page 3: CMSC421: Principles of Operating Systems

3

Coalescing

kernel

Text region

stack

free

allocated malloc(200)brk

Page 4: CMSC421: Principles of Operating Systems

4

Jobs of a memory allocator like malloc

Manage heap space in virtual memory– Use sbrk to ask for more memory from OS

Coalescing Keep track of free blocks Merge them together when adjacent blocks

are free Malloc needs to be really fast

Decide which free block to allocate Lets take a look at the data structure that is

used for implementing malloc and free

Page 5: CMSC421: Principles of Operating Systems

5

Memory layout of the heap

http://gee.cs.oswego.edu/dl/html/malloc.html

this linked list can be ordered in different ways

Page 6: CMSC421: Principles of Operating Systems

6

Selecting the free block to allocate: Fragmentation

• Intuitively, fragmentation stems from “breaking” up heap into unusable spaces– More fragmentation = worse utilization

• External fragmentation– Wasted space outside allocated objects

• Internal fragmentation– Wasted space inside an object

Page 7: CMSC421: Principles of Operating Systems

7

Classical Algorithms

• First-fit– find first chunk of desired size

Page 8: CMSC421: Principles of Operating Systems

8

Classical Algorithms

• Best-fit– find chunk that fits best

• Minimizes wasted space

Page 9: CMSC421: Principles of Operating Systems

9

Classical Algorithms

• Worst-fit– find chunk that fits worst– name is a misnomer!– keeps large holes around

• Reclaim space: coalesce free adjacent objects into one big object

Page 10: CMSC421: Principles of Operating Systems

char * x = new char[16];

10

virtual memory layout

Allocate some memory

0x40001000

0x40001040 → 0x4000104F

A Day in the Life of a Page

Page 11: CMSC421: Principles of Operating Systems

char * x = new char[16];

11

virtual memory layout

Update page tables

0x40001000

0x40001040 → 0x4000104F

physicalmemory

layout

A Day in the Life of a Page

Page 12: CMSC421: Principles of Operating Systems

strcpy(x, “hello”);

12

virtual memory layout

Write contents – dirty page

0x40001000

0x40001040 → 0x4000104F

physicalmemory

layout

A Day in the Life of a Page

Page 13: CMSC421: Principles of Operating Systems

13

virtual memory layout

Other processes fill up memory…

physicalmemory

layout

A Day in the Life of a Page

Page 14: CMSC421: Principles of Operating Systems

14

virtual memory layout

Forcing our page to be evicted (paged out)

physicalmemory

layout

swapspace(disk)

A Day in the Life of a Page

Page 15: CMSC421: Principles of Operating Systems

15

virtual memory layout

Now page nonresident & protected

physicalmemory

layout

swapspace(disk)

A Day in the Life of a Page

Page 16: CMSC421: Principles of Operating Systems

y[0] = x[0];

16

virtual memory layout

Touch page – swap it in

0x40001000

0x40001040 → 0x4000104F

physicalmemory

layout

swapspace(disk)

A Day in the Life of a Page

Page 17: CMSC421: Principles of Operating Systems

y[0] = x[0];

17

virtual memory layout

Touch page – swap it in

0x40001000

0x40001040 → 0x4000104F

physicalmemory

layout

swapspace(disk)

A Day in the Life of a Page

Page 18: CMSC421: Principles of Operating Systems

18

Talked about malloc? What about physical frame mgmt?

malloc works in virtual memory (works in user space)– Manages free blocks– Allocates virtual address on the heap

Remember the OS still has to manage physical frames The problem that the OS faces with physical

frame allocation is the similar to malloc Manage physical frames that all processes in

the system requests. Difference with malloc

Has to work across all processes Each process perceives 4GB of space, but

in actuality there is only 4GB of physical memory space

Page 19: CMSC421: Principles of Operating Systems

19

Tasks of the OS physical page management unit

Allocate new pages to applications– OS do this lazily– malloc call would usually return immediately – OS allocates a new physical only when the

process reads/writes to the page– Similar to the Copy-on-Write policy for fork()

In the event that all physical frames are taken OS needs to evict pages

Take page from main memory and store it on swap space

Needs a policy for evicting pages

Page 20: CMSC421: Principles of Operating Systems

20

Page replacement policy for Demand Paging?

What is the optimal page replacement policy?

Page 21: CMSC421: Principles of Operating Systems

21

Optimal Page Replacement policy

Find the page that is going to used farthest into the future– Evict the page from main memory to swap

space– Allocate the freed page to the new process– Problems: it is impossible to predict the future

Approximation is LRU (least recently used page) Find the page that is least recently used and

evict it Remember this has to be super-fast What would be techniques to implement

this in the kernel?

Page 22: CMSC421: Principles of Operating Systems

22

A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 23: CMSC421: Principles of Operating Systems

23

A1 A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 24: CMSC421: Principles of Operating Systems

24

A1

B2

A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 25: CMSC421: Principles of Operating Systems

25

A1

B2

C3

A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 26: CMSC421: Principles of Operating Systems

26

A1

B4

C3 A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 27: CMSC421: Principles of Operating Systems

27

A1

B4

C5

A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 28: CMSC421: Principles of Operating Systems

28

A1

B4

C6 A, B, C, B, C, C, D

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

Page 29: CMSC421: Principles of Operating Systems

29

A, B, C, B, C, C D, A1

B4

C6

D7

LRU page How should we implement this?

Implementing Exact LRU

• On each reference, time stamp page• When we need to evict: select oldest page

= least-recently used

A0

Page 30: CMSC421: Principles of Operating Systems

30

Implementing Exact LRU

• Could keep pages in order– optimizes eviction– Priority queue:

update = O(log n), eviction = O(log n)

• Optimize for common case!– Common case: hits, not misses– Hash table:

update = O(1), eviction = O(n)

Page 31: CMSC421: Principles of Operating Systems

31

Cost of Maintaining Exact LRU

• Hash tables: too expensive– On every reference:

• Compute hash of page address• Update time stamp

Page 32: CMSC421: Principles of Operating Systems

32

Cost of Maintaining Exact LRU

• Alternative: doubly-linked list– Move items to front when referenced– LRU items at end of list– Still too expensive

• 4-6 pointer updates per reference

• Can we do better?

Page 33: CMSC421: Principles of Operating Systems

33

A1

B1

C1 A, B, C, B, C, C, D

Hardware Support and approximate LRU (Linux Kernel)

• Maintain reference bits for every page– On each access, set reference bit to 1– Page replacement algorithm periodically resets

reference bits

Page 34: CMSC421: Principles of Operating Systems

34

A0

B0

C0

A, B, C, B, C, C, D

reset reference bits

Hardware Support

• Maintain reference bits for every page– On each access, set reference bit to 1– Page replacement algorithm periodically resets

reference bits

Page 35: CMSC421: Principles of Operating Systems

35

A0

B1

C0 A, B, C, B, C, C, D

Hardware Support

• Maintain reference bits for every page– On each access, set reference bit to 1– Page replacement algorithm periodically resets

reference bits

Page 36: CMSC421: Principles of Operating Systems

36

A0

B1

C1

A, B, C, B, C, C, D

Hardware Support

• Maintain reference bits for every page– On each access, set reference bit to 1– Page replacement algorithm periodically resets

reference bits

Page 37: CMSC421: Principles of Operating Systems

37

A0

B1

C1

A, B, C, B, C, C, D

Hardware Support

• Maintain reference bits for every page– On each access, set reference bit to 1– Page replacement algorithm periodically resets

reference bits

Page 38: CMSC421: Principles of Operating Systems

38

A0

A, B, C, B, C, C, DB1

C1

D1

Hardware Support

• Maintain reference bits for every page– On each access, set reference bit to 1– Page replacement algorithm periodically resets

reference bits– Evict page with reference bit = 0

• Cost per miss = O(n)

Page 39: CMSC421: Principles of Operating Systems

39

A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case:

Page 40: CMSC421: Principles of Operating Systems

40

A A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 41: CMSC421: Principles of Operating Systems

41

A B A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 42: CMSC421: Principles of Operating Systems

42

A B C A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 43: CMSC421: Principles of Operating Systems

43

A B D A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 44: CMSC421: Principles of Operating Systems

44

A B D A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 45: CMSC421: Principles of Operating Systems

45

A B D A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 46: CMSC421: Principles of Operating Systems

46

A B D A, B, C, D, A, B, C, D, ...size of available memory

Most-Recently Used (MRU)

• Evict most-recently used page• Shines for LRU’s worst-case: loop that exceeds

RAM size

Page 47: CMSC421: Principles of Operating Systems

47

FIFO

• First-in, first-out: evict oldest page• As competitive as LRU, but

performs miserably in practice!– Ignores locality– Suffers from Belady’s anomaly:

• More memory can mean more paging!– LRU & similar algs. do not

• Stack algorithms – more memory means ≥ hits

Page 48: CMSC421: Principles of Operating Systems

48

Tricks with Page Tables: Sharing

• Paging allows sharing of memory across processes– Reduces memory

requirements• Shared stuff includes

code, data– Code typically R/O

Page 49: CMSC421: Principles of Operating Systems

Tricks with Page Tables: COW

• Copy on write (COW)– Just copy page tables– Make all pages read-only

• What if process changes mem?

• All processes are created this way!

Page 50: CMSC421: Principles of Operating Systems

50

In-class Discussion