Linux Kernel Architecture

Chapter 18: Page Reclaim and Swapping

following three conditions must apply before the page can be moved back to the start of the list of

active pages:

1. As discussed in Chapter 4.8.3, the reverse mapping mechanism provides the
   page_referencedfunction to check the number of processes that have used a page since
   the last check. This is done by referring to corresponding status bits of the hardware that are
   held in the individual page table entries. Although the function returns the number of pro-
   cesses, it is only necessary to know whether at least one process has accessed the page, that
   is, whether the value returned is greater than 0. The condition is satisfied if this is the case.


2. reclaim_mappedis equal to 0; that is, mapped pages are not to be reclaimed.


3. The system has no swap area and the page just examined is registered as an anonymous
   page (in this case, there is nowhere to swap the page out).

Recall that Section 18.6.3 discussed how the call topage_referencedandpossiblymovingthepageto

the inactivity list afterward fit into the big picture of deeming a page active or inactive.

The kernel enters the third and final phase ofrefill_inactive_zoneonce all pages have been redis-

tributed from the zone-specificactivelist to the temporary locall_activeandl_inactivelists. Again

there is no need for a separate code flow diagram.

The last step entails not only copying the data in the temporary lists to the corresponding LRU lists of the

processed zone, but also checking whether there arepages that are no longer used (their usage counters

are equal to 0) and can be returned to the buddy system.

To do this, the kernel iterates sequentially over all the pages that have accumulated in the locall_active

andl_inactivelists. It handles all the individual pages in the same way:

❑ Pages taken from the tail of the local listszone->active_listorinactive_listare added to

the head of the zone-specific active or inactive LRU lists, respectively.

❑ Thepageinstance is added to a page vector. When this is full, all its pages are transferred col-

lectively to__pagevec_release, which first decrements the usage counter by 1 and then returns

the memory space to the buddy system when the counter reaches 0.

All the kernel need do after placing the processed pages back on the zone-specific lists is update a few

variables relating to memory management statistics.

18.6.7 Reclaiming Inactive Pages

Up to now, the pages in a zone have been redistributed on LRU lists to find good candidates

for reclaim. However, their memory space has not been released. This final step is performed

by theshrink_inactive_listandshrink_page_listfunctions, which work hand-in-hand.

shrink_inactive_listsgroups pages fromzone->inactive_listinto chunks, which benefits swap

clustering, whileshrink_page_listpasses the members on the resulting list downward and sends the

page to the associated backing store (which means the page is synchronized, swapped out, or discarded).

This apparently simple task, however, gives rise to a few problems, as you will see below.

Besides a list of pages and the usual shrink control parameter,shrink_page_listaccepts another param-

eter that allows two modes of operations:PAGEOUT_IO_ASYNCfor asynchronous andPAGEOUT_IO_SYNC