Thu, 13 Jul 1995 13:54:37 -0400
>1) [pinned, non-checkpoint objects] are useful for things like
We checkpointed the frame buffer pages on the 88K so we could restore the
screen after restart.
I chose a bad example. I was thinking about things like the temporary
storage used by the TCP/IP protocol stack. Because the protocol
wasn't designed with copy avoidance in mind, a TCP/IP implementation
often has to make multiple copies of your data between the wire and
the program. If we restart, the wire is going to be lost anyway, and
(logically) so are the intermediate copies.
If performance is an issue, pinning those buffering pages may make
sense. Since they are semantically garbage after recovery, there
really isn't any reason to checkpoint them in the first place.
>2) Alternatively, distinguish pinned from non-checkpointed. If a page
>is pinned and non-checkpointed, the kernel must conspire always to be
The standard old KeyKOS included this kind of logic as a checkpointing
Oops. Yep, I meant pinned and checkpointed. Thanks.
As I understand it, the KeyKOS kernel could get into states where it
didn't have an allocatable frame handy and the page was still hazarded
by checkpoint. In such cases, the caller would block until the page
was unhazarded. If the page is pinned, it seems to me that such
blocking needs to be avoided.
Another way to look at the whole issue is to think of such pages as
being checkpointed at a different (infinitely slow) rate from the rest
of the machine.
For pinned pages, you would have to ensure that a free page was
available. At a minimum you would have to ensure that, at all
times, the number of unchanged unpinned pages in the system was
greater than the number of pinned R/W pages.
In EROS it may be worse than that. One of the things that was lost
when I gave up key chains was any straightforward way to forcibly
reclaim a page other than by running the page ageing strategy.