Technical Women

049
Figure 1. Linda Betzold

Nineteen by Tegan and Sara

Today

  • Page replacement policies.

Midterm Procedures

  • We will use a randomized seating chart posted on Discourse (a few hours

  • Enter silently.

  • Bring your UB ID card, writing materials, and water (optional) to your seat.

    • Leave everything else at the front, back, or sides of the room: coats, bags, smartphones.

  • A customized exam will be waiting for you at your seat.

  • Find your exam and get to work.

Please note:

  • No make up exams will be given. Be here or get a zero.

  • This is a small room. Please come early so everyone can get seated.

  • This is a 50 minute exam. Please come early so we can get started.

  • The exam room will be videotaped.

  • Smartphone use during the exam will result in immediate ejection and failure.

Midterm Questions?

ASST3 Questions

  • ASST3.1 is due a week after the midterm.

  • If you are working alone, please contact the course staff.

Review: TLB v. Page Faults

We distinguish between two kinds of memory-related fault:

  • TLB Fault: a required virtual to physical address translation is not in the TLB.

  • Page Fault: the contents of a virtual page are either not initialized or not in memory.

Every page fault is preceded by a TLB fault.

  • If the contents of the virtual page are not in memory, a translation cannot exist for it!

Not every TLB fault generates a page fault.

  • If page is in memory and the translation is the page table, the TLB fault can be handled without generating a page fault.

Review: Swap Out

To swap a page to disk we must:

  1. Remove the translation from the TLB, if it exists.

  2. Copy the contents of the page to disk.

  3. Update the page table entry to indicate that the page is on disk.

Review: Swap Out

swapoutexample 1
swapoutexample 2
swapoutexample 3
swapoutexample 4
swapoutexample 5
swapoutexample 6
swapoutexample 7
swapoutexample 8
swapoutexample 9
swapoutexample 10

Review: Swap In

When must we swap in a page?

  • When the virtual address is used by the process!

To translate a virtual address used by a process that points to a page that has been swapped out, we must:

  1. Stop the instruction that is trying to translate the address until we can retrieve the contents.

  2. Allocate a page in memory to hold the new page contents.

  3. Locate the page on disk using the page table entry.

  4. Copy the contents of the page from disk.

  5. Update the page table entry to indicate that the page is in memory.

  6. Load the TLB.

  7. Restart the instruction that was addressing the virtual address we retrieved.

Review: Swap In

swapinexample 1
swapinexample 2
swapinexample 3
swapinexample 4
swapinexample 5
swapinexample 6
swapinexample 7
swapinexample 8
swapinexample 9
swapinexample 10
swapinexample 11

Hardware-Managed TLBs

  • On certain (common) architectures the MMU will search the page table itself to locate virtual-to-physical address translations missing from the TLB.

    • Pro: hardware is faster!

    • Con: operating system must set up the page tables in a fixed way that the hardware understands.

  • With a hardware-managed TLB, the kernel never sees TLB faults: they are handled in hardware.

  • Don’t worry: System/161 has a software-managed TLB, so you get to do all of the hard work and design your own page table structures!

Swapping: Questions?

Page Eviction

In order to swap out a page we need to choose which page to move to disk.

In order to swap in a page we might need to choose which page to swap out.

Swapping cost-benefit calculation:

  • Cost: mainly the time and disk bandwidth required to move a page to and from disk.

  • Benefit: the use of 4K (or a page) of memory as long as the page on disk remains unused.

There are tricks that the operating might play to minimize the cost, but mainly we will focus on algorithms designed to maximize the benefit.

(Another complementary description of our goal is minimizing the page fault rate.)

Page Eviction FAIL: Thrashing

Thrashing is a colloquialism normally used to describe a computer whose virtual memory subsystem is in a constant state of paging, rapidly exchanging data in memory for data on disk, to the exclusion of most application-level processing. This causes the performance of the computer to degrade or collapse.

— Wikipedia

Maximizing Benefit

Benefit: the use of 4K of memory as long as the page on disk remains unused.

How do we maximize the benefit?

  • Pick the page to evict that will remain unused the longest!

The Best Bet

What is the absolute best page to evict, the one that page replacement algorithms dream about?

  • A page that will never be used again!

Break Out the Ball

Think back to scheduling algorithms. (This is a bit simpler.)

What would we like to know about a page when choosing one to evict?

  • How long will it be before this page is used again?

The optimal scheduler evicts the page that will remain unused the longest. This clearly maximizes our swapping cost-benefit calculation.

  • This scheduler is difficult to implement!

What Now?

When we can’t predict the future, we…​ use the past to predict the future!

The Past Didn’t Go Anywhere

Intelligent page replacement requires three things:

  1. determining what information to track,

  2. figuring out how to collect that information, and

  3. how to store it.

There Be Tradeoffs

  • Collecting statistics may be expensive, slowing down the process of translating virtual addresses.

  • Storing statistics may be expensive, occupying kernel memory that could be better used for other things.

Simplest

What is the simplest possible page replacement algorithm?

  • Random.

Pros:

  • Extremely simple.

  • Good baseline for algorithms that try to be smarter.

Cons:

  • Too simple. We can probably do better.

Use The Past, Luke

What is an algorithm that uses a page’s past to predict its future?

  • Least Recently Used (LRU):

  • Choose the page that has not been used for the longest period of time.

  • Hopefully this is a page that will not be used again for a while.

Pros:

  • Might be as good as we can do without predicting the future.

Cons:

  • How do we tell how long it has been since a page has been accessed?

  • How do we store how long it has been since a page has been accessed?

LRU: Collecting Statistics

At what point does the operating system know that a process has accessed a virtual page?

  • When we load the entry into the TLB!

Does this reflect every virtual page access?

  • No! Only the first. A page that is accessed once and one that is accessed 1,000 times are indistinguishable.

Why not record every page access?

  • Too slow!

LRU: Storing Statistics

How much access time information can we store?

  • 32 bits = 232 "ticks", but doubles the page table entry size!

  • 8 bits = 256 "ticks".

How do we find the least recently used page?

  • Need some kind of efficient data structure holding all physical pages on the system that is searched on every page eviction.

Clock LRU

  • Simple and efficient LRU-like algorithm.

  • One bit of accessed information, set when loading a virtual address into the TLB.

To locate a page to evict:

  1. Cycle through all pages in memory in a fixed order.

  2. If a page accessed bit is clear, evict that page.

  3. If a page accessed bit is set, clear the bit.

Clock LRU

clock 1
clock 2
clock 3
clock 4
clock 5
clock 6
clock 7
clock 8
clock 9
clock 10

Clock Speed

What does it mean when the clock hand is turning slowly?

  • Little memory pressure, or

  • We are making good decisions about what to evict.

What does it mean when the clock hand is turning rapidly?

  • Lots of memory pressure, or

  • We are making bad decisions about what to evict.

Page Replacement: Questions?

Memory Management Design Exercise: Copy-on-Write

Remember the problem with fork?

  • Have to copy the entire address space of the parent!

  • If the parent has N pages allocated, we have to find N more free pages!

    • …​and then the child calls exec anyway.

Can we avoid this?

Copy-on-Write

Goal: don’t allocate any additional memory during fork, but preserve private address spaces.

Here’s what to do:

  1. During fork, point all child’s PTEs to the same physical memory as the parent.

  2. As long as the child and parent are both just reading from any shared page, we are OK.

    • Large parts of the address space may be read-only or read-mostly anyway…​

  3. As soon as either the child or the parent modifies the contents of any shared virtual page, we have to make a private copy.

  4. How do we trap writes? Mark the page as read only in the TLB!

Next Time

  • Midterm exam.

← →