[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcus Brinkmann
Subject: Re: why should physmem not know about which frames are extra?
Date: Wed, 27 Oct 2004 00:00:57 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]