Re: physmem/README clarification

[Neal H. Walfield]

At Mon, 03 Oct 2005 21:21:11 +0530,
Joe Steeve wrote:
> <quote>
> 
> Frames are multiplexed

That is, a task has access to N frames and uses M pages where M is
possibly greater than N.

> as well as shared across multiple tasks,

Frames can be shared e.g. a la system V shared memory segments or they
can be shared much like libraries using copy on write techniques.

> it
> is useful to reallocate frames in place.  In this way, data
> structures are not torn down just to be immediately recreated and
> gratuitous COWs are not performed.  container_release
> disassociates frames in a region with any shared frames.
> 
> </quote>
> 

Consider a task which reads a 4kb block from a file.  The file system
(approximately) locks the user supplied container, allocates a frame,
reads the data from backing store into the frame and enters the frame
into its block cache (in the process marking the frame copy on write).
Finally, it unlocks the container and returns to the caller.  The
result is that the file system and the client both a copy on write
reference to the frame.

Some times passes and the task feels memory pressure so it chooses a
frame to reuse.  The frame it chooses is the 4kb frame.  If it just
reuses then physmem will gratuitously perform a copy on write wasting
some cycles.  Of course, physmem doesn't that this is gratuitous.
Instead, the task could deallocate the frame and allocate a new frame
in its place.  This means two RPCs and that data structures torn down
in the first will just be recreated in the second.  Again, a waste of
cycles.  Instead, for this anticipated common case, we provide an RPC
to say: discard any pending copy on write on this frame as I don't
care about the contents anymore.

> I'm not able to understand the above. Can someone please give me a
> more detailed explanation.

Does this help?

Neal