[coyotos-dev] Scratch Pages, Fault on First Reference

[Jonathan S. Shapiro]

On Sun, 2006-01-15 at 11:21 +0100, Bas Wijnen wrote:
> On Sat, Jan 14, 2006 at 10:01:20PM -0800, Charles Landau wrote:
> > It may turn out that pinned scratch pages, unpinned scratch pages, 
> > pinned normal pages, and unpinned normal pages are four completely 
> > different types of objects, because they are allocated from different 
> > resource pools.
> 
> If it isn't too hard, it would probably be nice to be able to move pages from
> one of those states to the other.  If it is too hard (as I understand is the
> case for the pinned/not-pinned difference), then obviously it isn't really a
> problem if it isn't possible.

More than that, it is ESSENTIAL to be able to move pages from one state
to another.
 
> > This isn't sufficient, because a different thread of the application 
> > might make a second reference before the page is reinitialized. There 
> > needs to be some sort of state transition when the application has 
> > reinitialized the page.
> 
> I understood that this fault (which is guaranteed to be delivered) is a
> per-process flag which can be set by the kernel and reset by the application.

It is not a per-process flag, and even if it were, that wouldn't solve
the thread race in a system where thread==process.

The flag is on each page individually.


However, Charlie is correct about the race, and this suggests (to me)
that the FRF state may need to get reset explicitly, which partially
defeats the purpose of it. I think I need to step back and describe what
we are trying to accomplish and look at this again.

More later.

shap