Re: Comparing "copy" and "map/unmap"

[Jonathan S. Shapiro]

On Wed, 2005-10-12 at 13:52 +0200, Matthieu Lemerre wrote:
> "Jonathan S. Shapiro" <address@hidden> writes:
> 
> > On Tue, 2005-10-11 at 01:15 +0200, Matthieu Lemerre wrote:
> >> "Jonathan S. Shapiro" <address@hidden> writes:
> >
> >> > But I think that the real difference lies in the fact that our system
> >> > tends to favor designs where storage used by a server is allocated from
> >> > a homogeneous source. This greatly simplifies matters.
> >> 
> >> What do you mean by homogeneous source?
> >
> > I mean that in most of our objects, all of the storage comes from a
> > single storage allocator. As long as there is only one source of
> > storage, there is no complexity managing it. The complexity only begins
> > when you must manage storage from more than one source.
> 
> And different clients have different storage allocators, so the
> problem arise when one server has to provide objects allocated by
> several clients.

Yes. And it is sometimes a pain, but those cases are fortunately rare.
But here is another way to look at it:

  In most systems, there is no accountability for storage at all.
  This means that you don't have to worry about mixing up sources
  of storage, but it also means that you have absolutely no ability
  to control storage abuse and storage denial of service.

  In any system where storage allocation is accountable, there must
  be some abstraction in the system that captures the notion of a
  "right to allocate storage" (this is also a natural place to do
  the counting). The benefit of accountability is that you gain
  control. The cost of accountability is that you now need to 
  deal with the issue.

This appears to be one of those places where a foundational policy
decision must be made. The policy decision is: "Will we make storage
accountable?" The answer determines whether it is possible to prevent
resource denial or not.

Hmm. That is not quite precise. I can do storage accountability without
imposing limits, and this does not resolve the problem of storage
denial; it simply provides a measurement tool. In practice, the real
problem with storage accountability is that I must now worry about what
happens when somebody wishes to reclaim storage, and in order for that
to work in a vaguely sensible way I must ensure that a single object
does not destroy its underlying storage from multiple sources that might
be independently revoked. If you will pardon an abused metaphor: half an
object is not always better than none.

However, here is an analogous problem. Consider a real-time system where
we have dynamic libraries. Imagine that each real time process has a
quota for page frame pinning. Obviously, we would like to avoid
redundantly pinning the shared C library, but managing this is exactly
an example of mingled backing resource.

In the specific example of the C library, the right answer is probably
that it should simply be pinned globally by the system, but for other
libraries that answer becomes progressively less appropriate as the
library is less universally used.

Of course, I could also simply let everyone use the same space bank.
This "solves" the mingled resource problem at the cost of eliminating
all control over storage.

Any of these resolutions is possible using the EROS mechanism.

> > The time server is not a good example. In the case of the time server,
> > the right thing is for the server to allocate a *single* page from
> > *server* storage, put all three times in it, and simply hand out
> > read-only capabilities to that page. All clients access the same page.
> 
> I was going to object and ask : when is the storage freed then?  And I
> realized that this time server would have been set up by one client,
> and its storage would have been the client's storage.  I imagine that
> the client has then special control over the server to create the time
> objects.
> 
> Now I think that I see how this works. 

Umm. I think you see how it works, but the time server is still a bad
example. As a practical matter, the time server probably wants to be a
system-wide resource that uses a fixed amount of global storage. So in
practice, its storage will come out of the pool granted to the installer
by the system installation process.

> Thanks.  I have now a much clearer idea of how it works, and I now
> believe that we can indeed get rid of reference counting.

If that proves to be correct, it would be wonderful. Let us see what
other places reference counting is currently used that may still
surprise us.

shap