real time and self paging

[Neal H. Walfield]

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.  I agree that this scheme would be
problematic for real-time applications thus requiring that real-time
applications ensure that they are the exclusive user of all frames
they need.  I am not sure, however, that this is the only valid
sharing scheme.  I think it may be possible to design a scheme such
that when A changes its resident set, it cannot implicitly change B's.

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*.  The implication is that there can be up to X extant
reservations.  The manager also provides a mechanism to clone a
reservation (i.e. given a reservation bank and a frame, create a
logical copy of the frame).  Say A agrees to copy F to B.  B may
provide a reservation bank to A which A uses to create a clone of F,
F' and then passes F' to B.  Eventually, A has memory pressure and
decides to drop F.  It destroys F but the frame underlying F is not
destroyed as F' still uses it.  I don't consider this garbage
collection as each party pays for the resource.

There are two issues to deal with: paging and unused memory.

Say A pages F to banking store instead of simply dropping it.  If a A
later pages it back in by reading the data into a new frame, the
amount of sharing has been reduced and I/O bandwidth has potentially
been wasted.  Instead, we join the memory manager and the backing
store manager.  Now, to page F to banking store, A invokes the page
out RPC on F and passes a space bank.  Since F' still names the frame,
the memory manager needn't write F to disk immediately.  It can wait
until F' is also paged out (or changes since this is a COW copy)
before actually sending the page to disk.  Say A requires the page
again, before B destroys F'.  In this case, the frame can be
recovered.

The second problem is unused memory: if we limit the number of
reservations in the system to the total number of frames and there is
a high amount of sharing, then it would seem that memory would be
under utilized.  This memory can be used for caching.  My
understanding is that approximately half of physical memory is
dedicated to the buffer caches.


I curious if you think this approach still suffers from the problem
you pointed out or if you recognize other issues.

Thanks,
Neal