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

[Marcus Brinkmann]

At Tue, 26 Oct 2004 22:46:56 +0100,
Neal H. Walfield wrote:
> 
> 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.

In that case I would hardly count the page in question to be an extra
frame, it would have to be considered by the task as a guaranteed
frame.  It would be extra before and after the operation, but not
during.

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

Yes.  Or in other words: Nasty evilness ahead. :)

Marcus