Chuck Silvers wrote:
> 
> > Adding a panic mode where the page daemon (or a second daemon) starts hunting
> > for easily recyclable clean pages while ignoring reference bits might 
> > also be a good idea.
> 
> this would probably avoid a substantial portion of low-memory problems,
> but it's not really a solution.  I'd rather see something that is more
> algorithmically robust.

I agree - this is just a duct-tape solution.
A real solution probably needs to keep track of the number of
known dirty pages and potentially dirty pages (Pages with active writable
mappings) and deny new writable mappings based on the number.
Currently I am not prepared to open this can of worms.

> > Chuq Silvers memory balancing additions make things a little bit tricky.
> > Currently I am leaning toward implementing different queues for 
> > files/exec/anon.
> > Since file pages can become exec pages (and then file pages again) strict 
> > book-keeping would be to expensive. However with lazy transfer of pages 
> > between
> > the page type queues I believe a good approximation can be reached.
> > ( Perhaps with the exception of small memory systems)
> 
> this idea came up a while back too.  the drawback to this approach is that
> you lose track of the relative ages of the different types of pages.
> this may not turn out to be a problem in practice, though.
> I didn't get a chance to try this out either.

It depends - I will probably at first just create "page type" queues for pages 
kept in memory due to the uvmexp.XXXXmin values.
The pagedaemon will put pages on these lists from the inactive list 
if the number of XXXX page type pages is below their uvmexp.XXXXmin values.
The pagedaemon will deactivate pages from these list instead of the inactive
list once the number of pages of the type is above the  uvmexp.XXXXmin value.

This should prevent the pagedaemon from playing Mary-go-round with these 
pages and keeps better track of the LRU information.
( Don't ask me yet where the planed clean pages queue will be in relation
  to the page type queues ;-) 

> the current exact counting of the page types will have to go eventually
> anyway, since such global counters have poor MP scalability.  similarly
> for the global pageq lock and its use for locking the "owner" (anon vs. obj)
> for pages.  it doesn't seem like these will be significant problems for
> quite a while yet, though.

After roasting the "Giant" (kernel lock) pig ? ;-)


	Stephan