[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Meaning of self-paging
Jonathan S. Shapiro
Meaning of self-paging
Fri, 13 Jan 2006 20:55:22 -0500
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
voluntary pageout: sending individual pages back to the store on
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
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.
Re: Is the list still working?, Jonathan S. Shapiro, 2006/01/11
- Re: Is the list still working?, (continued)