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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
