Meaning of self-paging

[Jonathan S. Shapiro]

Bas (and others) have been advocating self paging. At a very high level,
the idea is that an application should fully control all of its page-in,
page-out, and replacement policy. Discussion of these issues tends to
drag considerations of pinning into the picture as well.

Setting aside any fondness for self-paging in particular, let's look at
the goals that we might actually be trying to satisfy:

  pinning control: ensuring that requires frames remain in core
  interference control: ensuring that heavy paging by one application
      does not negatively impact another.
  opportunistic caching: finding a way to make effective use of
      idle frames
  voluntary pageout: sending individual pages back to the store on
      purpose

In the context of Coyotos, I would add one more:

  explicit page zero: setting a page to zeros in a way that the
     the kernel can optimize to avoid the associated block I/O.

Finally, I would like to add an observation:

  Page write-back may be done opportunistically, but page frames
  should be reclaimed only in response to memory pressure. The
  ONLY reason to drop a frame that has known content is that you
  need the frame for something else.

  Contrast this with the Linux aging policy. Turn on DPMS and leave
  your display for a couple of hours. The ager will happily page your
  entire memory out, and when you tap the mouse you'll spend 15 minutes
  paging all of that crap back in.

  So: temporal aging is actually a bad idea. What you want is
  generational aging that happens only in response to memory pressure.

Looking at the goals above, it should be immediately apparent that two
of them conflict very fundamentally: most of the reason that we want
interference control is that we allow far too much opportunistic
caching. I want to come back to this one, because solving it in a way
that is compatible with user-mode paging is probably not possible.


Next, let me remind us of three fundamental design principles of
robustness:

  1. A more critical subsystem must never rely on the correct behavior
     of a less robust subsystem.

  2. Robust systems should be as deterministic as possible. Timeout
     based recovery mechanisms are necessary in certain places, but
     they should only be used in connection with behaviors where a
     wall clock bound is externally specified.

  3. Every "artificial" wall clock bound (i.e. one not associated with
     a real-world device) is a source of non-determinism, and makes the
     system less robust. In practice, these cases are rarely tested, and
     their transitive impact in the system is *certainly* not tested.

Taken together, these three principles mean that a pageout design of the
form "try the user app, and if it doesn't respond in X time, use a
fallback" is simply a bad idea if want the design to be robust. Rather,
this is a place where the preferred architectural approach is to find a
design that does not require a fall-back plan in the first place.


Okay. So let me take the issues above in separate notes.