Hi Jason,

I don't think removing the "reactivate" path is the way to go.
Pages with long duration pmap-mappings would be at a disadvantage
compared to pages that are often freshly entered into the pmap.
( Pages that are in constant use might be paged out if
  no new fault occurs on the page) 

Currently the page daemon does not clear the access attribute
before moving the page to the inactive queue.
Doing so would more faithfully emulate the two-handed-clock algorithm.
Changing the inactive target and scan rate based on demand should
further help things along.
( It has been  10 years since I taught this stuff in "SunOS Internals" classes
- I will try to dig up my notes to refresh my memory)

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

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)

However I am currently working on UVM screwed into a FreeBSD 5.x kernel
and I have to do some cleanup and some other projects before I can experiment
with page daemon optimizations.
This means it will take a while until I can offer some patches for NetBSD.


	Stephan 




Jason Thorpe wrote:
> 
> Hi folks...
> 
> I think it's time to remove the generic "reactivate" path from the 
> inactive queue scan.  Or at least adjust how it works.
> 
> Take a look at uvm_pdaemon.c:452.  In January, 2001, I added this code 
> to improve the performance of the system under moderate to high memory 
> and I/O load.  What it does is move a page that has been referenced 
> back to the active queue.  This actually implements the 
> two-handed-clock algorithm the way I think was intended:
> 
> 	1. Active pages are scanned.  Pages that have not been referenced
> 	   since the last active scan are moved to the inactive queue.
> 
> 	2. Inactive pages are scanned.  Pages that have been referenced
> 	   since being put on the inactive queue are moved back to the
> 	   active queue.  Otherwise, the page is cleaned / freed.
> 
> The idea is that this finds your working set and keeps it in core.
> 
> However, I've recently discovered a serious problem with this.  
> Basically, if you have some VERY ACTIVE files that consume nearly all 
> physical memory, those pages will always be reactivated.  This 
> effectively defeats the memory usage balancing that was added by Chuq 
> Silvers a couple of months later.  E.g. consider you have your "vnode 
> page" threshold tuned to 50%, but they're currently consuming 80%.  
> Suddenly you need to free a page, but all those file pages are 
> active... they get reactivated without any consideration for the page 
> type.  Now let's say your low water mark for the other types are set 
> higher than their current usage... suddenly you can't free ANY pages, 
> and some poor process gets shot in the head - "out of swap".
> 
> Does anyone have any thoughts on how to fix this problem?  I'm inclined 
> to kill the reactivation path completely, but I would prefer reactivate 
> an actually active page of a certain type than an inactive one.
> 
>          -- Jason R. Thorpe <thorpej@wasabisystems.com>