Subject: Re: Page reactivation path in pdaemon -- time to remove it?
To: Stephan Uphoff <ups@tree.com>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 03/03/2004 19:29:35
On Fri, Feb 27, 2004 at 02:35:49PM -0500, Stephan Uphoff wrote:
> I am planning to add a small page queue for clean pages between
> the inactive and the free queue since I don't like the way that the
> page daemon reacts to a cluster of dirty pages.

I thought about this some years back and it seemed like a good idea,
but I never got around to trying it out.  I'm interested in what you
discover.


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


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

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.


> However I am currently working on UVM screwed into a FreeBSD 5.x kernel

hee, fun.

-Chuck