Virtual Memory (Ch. 9)
description
Transcript of Virtual Memory (Ch. 9)
![Page 1: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/1.jpg)
Virtual Memory (Ch. 9)
![Page 2: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/2.jpg)
Look at two logically identical java demo programs: workset1 and workset2. Can do same programs using Eclipse. Run each and explain the difference
![Page 3: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/3.jpg)
Array accesses are via paging techniques described previously:
However, when the page table is accessed there are 2 possibilities: valid bit set to 1 and entry contains frame#: proceed as before
![Page 4: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/4.jpg)
valid bit set to 0; page not in memory; page fault; OS must do an I/O to get page and store into
memory. Fig. 9.5
![Page 5: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/5.jpg)
Page fault causes the following: OS trap save registers and process state determine cause of interruption
![Page 6: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/6.jpg)
find page location on disk initiate a read from the disk request sits in queue until acted on wait for disk movements transfer data from disk to OS memory buffer
![Page 7: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/7.jpg)
meantime allocate cpu to another process get interrupt from controller (I/O done) save registers and process state for currently
running process (context switch) determine cause of interrupt update page table
![Page 8: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/8.jpg)
wait for cpu to be allocated to this process restore registers and process state. Fig. 9.6
![Page 9: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/9.jpg)
Demand paging: pages fetched as needed (most common)
Anticipatory paging: requested page and nearby ones all fetched.
![Page 10: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/10.jpg)
effective access time (eat): p=probability of a page fault. eat=(1-p)*memory access time + p*page fault
time. Some numbers on page 357.
![Page 11: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/11.jpg)
fork() command traditionally copies all of parent's pages copy on write: vfork()
initially parent and child share pages if a shared page is written to, copy the page and
map it to the virtual space. look at demo fork.c: Replace fork() with vfork() and note the
difference.
![Page 12: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/12.jpg)
page replacement: During a page fault, an incoming page may
have to replace a page currently in memory. Which one?
Note: Replaced pages must be saved only if modified.
Page table has a "dirty bit" to indicate an updated page
(Figs 9.9-9.10)
![Page 13: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/13.jpg)
Replacement strategies FIFO: Figure 9.12
does not always perform well (replaced pages could be ones used throughout the process)
more frames => fewer page faults in general: empirical data demonstrates this (Fig 9.11)
![Page 14: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/14.jpg)
However, it can NOT be proved It CAN be disproven:
Belady’s anomaly: Figure 9.12-9.13 Another example: Assume 3 or 4 frames and examine
page reference string 1-2-3-4-1-2-5-1-2-3-4-5. More faults with 4 frames!!
![Page 15: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/15.jpg)
3 frames:
![Page 16: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/16.jpg)
![Page 17: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/17.jpg)
optimal replacement (replace page not needed for the longest time) Fig 9.14 difficult to implement
don’t care replacement (replace any page) easy to implement. No attempt at achieving better performance.
![Page 18: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/18.jpg)
LRU replacement (replace page least recently used) Fig. 9.15 somewhat common Can implement by storing a logical clock value
(really just a counter) in page table entry. Can implement by maintaining a stack of page
numbers.
![Page 19: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/19.jpg)
NUR (not used recently) approximation Keep track of a reference (R) bit and a dirty
(D) bit for each page. Replace according to: R=0; D=0 R=0; D=1 R=1; D=0 R=1; D=1 Periodically reset R bit
![Page 20: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/20.jpg)
multiple reference bits Can keep an 8-bit byte of R-bits, once for
each of the previous 8 time intervals. At each new interval, shift bits right.
lowest 8-bit number identifies pages used less recently.
![Page 21: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/21.jpg)
Second chance Use FIFO but if R bit is 1, go to next page in
queue. (page gets a second chance) Linux and XP use variations of this (depending
on processor)
![Page 22: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/22.jpg)
Mention least and most frequently used (LFU and MFU). Neither is common.
FIFO with released page going into free page queue. May reclaim before page is allocated to another. No physical I/O.
![Page 23: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/23.jpg)
Allocation of frames How many frames per process?
Too few and frequent page faults and poor performance
May lead to Thrashing (walking the disk drives-a term used when drives were big and heavy and excessive I/O caused the drives to vibrate and actually start moving).
Too many and other processes have less room.
![Page 24: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/24.jpg)
Equal allocation: n processes get 1/n of the free memory
Proportional allocation: Let si be the size requirement of process i. Then S=s1+s2+…+sn. If m is the number of available frames, then allocate (si/S)m frames.
If s1=10 and s2=127 and m=62 then we allocate (10/137)62= (4 or 5) to first process and (127/137)62=57 or 58 to second
![Page 25: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/25.jpg)
Working Set model spatial and temporal locality patterns
Good use of locality poor use of locality
![Page 26: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/26.jpg)
TLBs should accommodate the working set See Fig 9.22 on p. 380
![Page 27: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/27.jpg)
Page size? larger page size means fewer frames, a
smaller page table, but larger internal fragmentation.
smaller page size means more frames, a larger page table, but less internal fragmentation.
![Page 28: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/28.jpg)
Common sizes are ½ K to about 4K. Larger memory sizes make smaller pages problematic; also fragmentation is less of a problem.
![Page 29: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/29.jpg)
Memory-mapped files: Map a disk block to a page in memory First access results in page fault as usual. Fault causes a page-sized portion of the file to
be brought into physical memory.
![Page 30: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/30.jpg)
Subsequent reads/writes are memory accesses.
(Figure 9.23 and Java program on Figure 9.25 and demo)
![Page 31: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/31.jpg)
Kernel memory: Available frames (for most processes) stored
in a list maintained by the Kernel.
![Page 32: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/32.jpg)
Kernel free-memory pool is separate. Reasons: Kernel code often not subject to a paging system.
Strive for efficiency and minimizing of internal fragmentation.
Some hardware driver must interact directly with physical memory (i.e. no virtual memory)
see page 384
![Page 33: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/33.jpg)
Buddy system: Allocate from a segment only chunks of size = 2p
for some p. Each segment consists of two buddies each half
the segment size. Each buddy divided into two buddies.
![Page 34: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/34.jpg)
Figure 9.26. Facilitates coalescing unused buddies into larger
segments Fragmentation is a problem. Used in early Linux
![Page 35: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/35.jpg)
Slab allocation Slab: one or more physical contiguous pages.
Usually one. Cache: one or more slabs one cache for each OS kernel structure (process
descriptors, file objects, semaphores, shared memory, message queues, etc)
![Page 36: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/36.jpg)
populated by objects of the associated type. Slab allocator allocates a portion of a slab for a
specified object Slabs divided into chunks the size of the
associated object – no fragmentation Effective when many
![Page 37: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/37.jpg)
Windows XP Demand paging with clustering (retrieves
faulting page AND a few pages after it) Processes initially given a working set
minimum and maximum (50 and 345 are cited)
Some book refs: p. 841, figs 22.3 and 22.4, p. 844
![Page 38: Virtual Memory (Ch. 9)](https://reader035.fdocuments.net/reader035/viewer/2022062315/568163e8550346895dd550da/html5/thumbnails/38.jpg)
Linux Some book refs: Figs 21.6 and 21.7, p. 805 Look at vmstat command. Also, top, slabtop,
free commands. Also, the Linux file /proc/slabinfo. Note: look for task_struct in the slabtop command results.
While the display is active, run a workset program and watch the values change.