Voluntary pageout (self-paging)

[Jonathan S. Shapiro]

In concept, voluntary pageout seems very simple. In the self-paging
scheme, the application advises the OS to remove some page, writing it
back if necessary. The page is now gone.

In practice, matters are more complicated. Consider an application that
performs denial of service by advising the OS that the code page holding
printf() is no longer of interest. So there is a problem: forced pageout
creates denial of service.

This means that it is too much authority for any application to be able
to forcibly page out a given page. What we want instead is a way for an
application to say (a) this application has no further use for this
page, and (b) *if* the page is not otherwise in use it should be cleared
and removed preferentially.

In discussion, it seems that there are two motivating use-cases that are
quite different. Let me first deal with explicit object pageout
initiated by the application:


My current proposal for how this should be done is that there should be
a capability-based operation of the form:

        advisory-age(some-space, some-address)

The effect of this operation is as follows:

  (a) all outstanding PTEs naming this object are invalidated (they can
      be rebuilt from in-memory state if the object is still in use)

  (b) the object's age is set to the generation where object write-back
      occurs

Following this operation, if a reference is made to this object, it's
age is made younger in the same way that the existing "last chance"
recovery mechanism works.

However, the actual decision of when/whether to remove the object
remains a decision of the kernel ager and cleaner.

One qualifying note: this operation applies only to objects that are
pageable. If an object is pinned, it is not a candidate for ageing, and
the operation is simply ignored.

Another: if it is the intent of the application to say "the content of
this page is no longer interesting", the application should first
execute a "kernel page zero" operation. This will eliminate most of the
writeback cost for this frame.


In discussions with Marcus and Neal, only one compelling use case for
this mechanism has emerged: temporary in-memory caching (e.g. for
expanded bitmaps). This is a much simpler situation, and it doesn't
really require the explicit management that I have described above. A
very simple alternative would be to create some means to say "this
region should age out at twice the standard rate" (the magic multiple
might not be 2, but you get the idea). This is actually very
straightforward to achieve.


shap