Re: why should physmem not know about which frames are extra?

[Marcus Brinkmann]

At Tue, 26 Oct 2004 15:17:33 +0100,
Neal H. Walfield wrote:
> When extra frames are in use, they cannot be dropped arbitrarily.
> There are two situations which immediately come to mind: when a server
> uses extra frames they nearly become guaranteed frames: the data is
> locked in core during the operation (although the operation is
> typically very short).  For instance, when extracting data from the
> cache, the server makes a (COW) copy of the frame for the client.
> Copying a frame into a container is not atomic.

I think this is a sub-argument of the argument that not all extra
frames are equal.  After all, the client will always have to deal with
the potential case that all extra frames _must_ be dropped because
physmem requests it.  It's true that you have some time to drop them,
and within that time I guess you could complete such a quick operation
in process.  But I have doubts, as the necessary timeout on the client
could defeat this.

> Extra frames are sometimes converted to guaranteed frames.  For
> instance, a page in a cache can be made dirty by writing to it.  Until
> the page is synchronized with the copy on backing store, it cannot be
> disposed.  The task need only maintain that the number of frames which
> it can easily expose of is greater than or equal to the number of
> allocated frames.

I have considered this case before writing my mail, and thought that
you theoretically could mark the particular frame as guaranteed (from
extra) when mapping it write-only (ie, you have to contact physmem
anyway).  This causes semantic confusion, but well, I don't think this
particular argument is a complete showstopper.
 
> Finally, just because a frame is designated as extra does not mean
> that its cost of recreation is equivalent to all other extra frames.

This is the best argument, in my opinion.  Although it could be
compensated by a sort of task-local priority you could set in physmem,
this would go into the wrong direction, and actually shows why my idea
is mistaken.  I concur, for now.  The actual policy should be in the
client, the mechanism in physmem.

I do feel somewhat unhappy about the time-out based notify-respond
mechanism that we will need to make this work.  IMO, that approach
also has a lot of hair.  But we can discuss this later, when we have
more details laid out.

Thanks,
Marcus