Page Replacement in Linux 2'4 Memory Management

1
Page Replacement in Linux 2.4 Memory Management

• Rik Van Riel

2
Outline

• Why do we need page replacement?
• How Linux 2.2 MM works.
• Changes made with 2.4 MM.
• To do list.
• Conclusion.
• Critique.

3
Page Replacement

• Finite amount of main memory.
• Need to move unneeded data out of memory to make
  room for newly required data.
• Actually, we approximate this.
• LRU, NRU, LFU
• Allows us to over-allocate memory.

4
Linux 2.2
5
Overview of 2.2

• Simplicity and Low Overhead.
• One large free list.
• Allocated to 7 memory pools.

6
Freeing Memory

• Kswapd thread is called to free memory.
• Try_to_free_pages( ).
• Frees unused slabs from kernel memory.
• The following four functions are called
• Shrink_mmap
• Shm_swap
• Swap_out
• Shrink_dcache_memory

7
Problems

• NRU is not as effective as LRU.
• Will sometimes evict clean, accessed pages before
  old, dirty pages.
• Can enter inappropriate states.
• Referenced bits set at greatly different times.

8
More Problems

• Unpredictable.
• Simple clock algorithm.
• Relies on other functions.
• Very sensitive to small changes.
• Fragile.

9
Linux 2.4
10
Changes Made Because

• Poor performance of 2.2 under some loads.
• Needed to be more predictable and easier to
  understand.
• Needed to be less sensitive to changes.
• Due to code freeze could only implement known
  good strategies.
• Needed access to more memory.

11
Page Aging (1/6)

• Implemented page aging to estimate LRU.
• Less overhead than LFU.
• LRU better predictor than LFU according to study.
• Keep track of an age for each page.
• Increment age by a constant when accessed.
• Divide age by two when not accessed.
• Age of 0, page is candidate for eviction.
• Only downward age from the physical-page based
  scanning of the active list.
• Helps shared pages (ie. The C library).

12
Multiple Page Lists (2/6)

• Keep a list of active pages and a separate list
  of inactive pages.
• Refill_inactive function keeps them balanced.

13
Dynamically Sized Inactive List (3/6)

• Inactive list size depends on VM activity.
• Balances age data with I/O clustering.
• Algorithm used allows
• Time for flushing optimizations.
• Good page age distribution.

14
Optimized Page Flushing (4/6)

• Avoids writing out dirty pages.
• Accumulates write-outs for I/O clustering.
• Reduces disk seek time.
• Use only clean pages while there are some.
• Gives good performance under light loads.
• Performance suffers under heavy write loads.

15
Background Page Aging (5/6)

• Process to scan pages in the background to add
  them to the inactive list.
• Performs modest scanning.
• Keeps overhead low.
• Only moves truly idle pages.
• Prepares the system for sudden memory demands
  arise.

16
Drop Behind (6/6)

• Counterpart to read ahead.
• Data used by streaming I/O is evicted more
  quickly.
• Helps other processes on the system.
• Allows streaming I/O to run more quickly.

17
To Do List

• Implement load control to avoid thrashing.
• Suspend processes round-robin.
• Implement RSS limits to control physical memory
  allocation.
• Improve balancing of page reclaiming.
• Implement read ahead and drop-behind for mmap()ed
  files.

18
Conclusion

• Results indicate 2.4 to be an improvement over
  2.2.
• Improved figures for throughput on server
  machines.
• Decreased sensitivity to change.
• These results indicate 2.4 to be a good
  foundation for future development.

19
Critique

• Changes made in 2.4 represent an improvement over
  2.2
• Paper needed some data showing how each change
  affected performance.
• Paper layout was not very good.
• Only 2 citations on citeseer.