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

[Neal H. Walfield]

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

It means that the task can have up to Y - X frames for cache data even
if physmem asks for all of the memory back.  The relative value of all
the frames changes with time (due to e.g. aging) so what group will be
different depending on when physmem asks for memory back.  That is, it
is in the tasks interest to create (at least) two classes of frames: G
frames and E frames where G frames are frames which cannot be dropped
arbitrarily and E frames are frames which satisfy the properties of
extra frames.  The task make sure that |E| is at least X.