Re: real time and self paging

[Jonathan S. Shapiro]

On Mon, 2005-11-07 at 11:15 +0100, Neal H. Walfield wrote:
> At Sat, 05 Nov 2005 12:49:46 -0500,
> Jonathan S. Shapiro wrote:
> >   2. Self-paging introduces complications for real-time systems where
> >      the "in memory" resources are shared. This is well known and well
> >      documented in the literature.
> 
> I think your assumption here is that if tasks A and B both have a
> capability, F, which names a frame, then if A chooses to evict F it is
> implicitly evicted for B.

This is not my assumption. I have indicated in a previous email that
this design is non-viable, because B's use would be disrupted. The most
that A can do is say "I no longer wish to sponsor the residency of this
frame".

> I think it may be possible to design a scheme such
> that when A changes its resident set, it cannot implicitly change B's.

I would be very interested to hear a design for such a scheme that
allows joint sponsorship of shared components (e.g. dynamic library
code). The reservations scheme that you outline does not suffice, and in
principle, I do not believe that this is possible without substantial
communication between the components.

This communication, obviously, is inconsistent with confinement. That
doesn't mean that we should reject it. It means that we need to be aware
that real-time programs require greater authority and trust.

> The solution I am think of is that instead of tasks choosing frames to
> evict they choose reservations to abandon.  In this scheme, there is a
> physical memory manager which manages X frames of physical memory.  It
> provides to types of objects: reservations and reservation banks.  A
> reservation refers to either a specific (e.g. a frame containing the
> page X) or a non-specific frame (e.g. an uninitialized frame).  A
> reservation is a guarantee that the specified frame is available
> *right now*....

In such a design, one of three things must be true:

  1. # reservations exceeds # frames, in which case the guarantee
     cannot be met, or
  2. Any process wishing to retain libc must sponsor it independent
     of the behavior of any other process. Therefore, these pages
     are redundantly reserved and the utilization of memory drops
     very dramatically, or
  3. Some negotiated scheme for residency is in force.

In the last case, the question will become: how sophisticated does the
negotiation need to be, and can we implement it centrally without
self-paging. I strongly suspect (but I do not know) that all of the
negotiation schemes that actually converge can be implemented centrally,
and that doing so is actually more efficient than self-paging.

I am not opposed to a reservation scheme similar to the one that you
describe, and in fact you and I discussed such a scheme at LSM. I simply
suspect that its usefulness declines more quickly than either of us will
like.

shap