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

[Neal H. Walfield]

At Tue, 26 Oct 2004 21:16:09 +0200,
Marcus Brinkmann wrote:
> 
> 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.

These are cases where the frame is in use and removing it would cause
a problem.  I don't see how that is a valuation of the frame.

>  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.

Not true.  If could be the case that the task has G + X frames in use
of which Y are clean and reproducible and hence considered to be extra
frames.  physmem may reclaim up to X, not Y, frames even if Y > X and
not equal to it.

> > 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.

I think creates a lot of confusion and this doesn't address the other
case major case: extra frames which are in use but not being written
to.

> 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.

Yes.  I was recently thinking that using CPU rather than wall clock
could be an approach to avoid finding a magic "number".  (This also
means more closely linking the scheduler and physmem or providing the
ability to watch events in the scheduler.)