Re: uvm_pageactivate, uvm_pageenqueue and uvm_pageqlock

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Jun 05, 2008 at 01:34:38PM +0900, YAMAMOTO Takashi wrote:

> > Hi,
> > 
> > With fork-intensive workloads there is a huge amount of contention on
> > uvm_pageqlock. Most of it comes from uvm_fault_internal, which passes
> > hints to the page replacement policy on ~every fault.
> > 
> > This patch changes uvm_pageactivate() and uvm_pageenqueue() to do an
> > unlocked check to see if operation actually needs to be done. Only if
> > true does it acquire the lock and call into the page replacement policy
> > to do the work.
> > 
> >     http://www.netbsd.org/~ad/activate.diff
> > 
> > I am not sure what should happen for clockpro's uvmpdpol_pageisactive_p(),
> > though.
> > 
> > Comments?
> > 
> > Thanks,
> > Andrew
> 
> how do you think about retiring explicit activate calls and
> setting page's reference bit using atomic ops instead?

Here's a better patch than the one I posted earlier:

        http://www.netbsd.org/~ad/uvm.diff

Some notes:

- It doesn't work yet. :-)

- One significant change is to merge pqflags and wire_count into a single
  field, so we can CAS on them safely. It may not be needed.

- It's a lot more complicated than I wanted and will have to wait until
  later. 

What about making all pages available to the page scanner for inspection,
instead of enqueueing and dequeueing them regularly? I think that with more
than 1 CPU, it's likely to cost a lot less CPU time than we currently waste
spinning on uvm_pageqlock.

Andrew