Re: Architecture of Backing Store Descriptors Jonathan Shapiro (shap@cobra.cis.upenn.edu)
Tue, 22 Nov 94 12:20:47 -0500

I'm a little confused.
Does "provide ageing ... services" mean treat main memory as a cache, with some replacement algorithm such as LRU? If so, I don't see how anything but the kernel could provide this.

Yes and no. The idea is that the kernel implements the aging logic, and sends advisories to the backing store managers when it is time to remove pages, but the actual removal is done by the managers.

It sounds like you are asking the kernel to do some of the work of the memory object manager. A cleaner structure is to have the memory object manager capability lead to the kernel instead of a process.

You're right, and on the face of it this seems to be a good argument for pulling some of the file system logic into the kernel. The whole point of the exercise, however, is to allow the memory object manager to be outside the kernel. In NewSys, the kernel in general has insufficient knowledge to be able to purge a page back to backing store (I grant that is a problem, and I'm working on it). I believe I have a model for working set management that makes this workable.

You have provided for mapping a subset of an object. I hope that is not all one can do with a memory object. Composition (one segment containing others) is a basic operation that should be allowed.

Claim: Memory object composition is essentially intertwined with the KeyKOS persistence architecture. In the absence of such persistence, it is not straightforward to maintain the nesting relationships across system restarts.

The KeyKOS approach to segment nesting blurs the distinction between the containment relationship and the object contained, which is the source of a curious (and I think important) semantic problem. When fielding a segment fault, there is a fundamental ambiguity about the order in which to invoke the segment keepers. For many common cases, reasonable arguments can be advanced for both top down and bottom up keeper invocations (or a mixture), depending on the *intent* of the mapping. A case can also be made for allowing a keeper to respond by passing the buck to the next enclosing keeper, which (if I understand things right) is not possible in the current KeyKOS system (though it's a straightforward addition).

In a distributed system, this ambiguity of fault handling is a significant problem. It makes it extremely difficult to design a coherency protocol that is generalizable to all memory objects independent of the rehosted OS.

My intent is that NewSys will use something more like the Mach approach (which may well prove to be a mistake). In NewSys, memory objects can NOT be composed. A memory object is a contiguous range of bytes, and exists independent of its mappings.

Actually, composition can be done in NewSys by having the object manager implement it, but my expectation is that this will prove to be an uncommon case.

Would you be kind enough to advance the case for why composition is a fundamental operation? Bear in mind that a NewSys address space is not a segment -- it's a collection of object mappings.

Jonathan