I have been using PDPOLICY_CLOCKPRO for weeks now, most recently
defining USEONCE2 and ADAPTIVE (see sys/uvm/uvm_pdpolicy_clockpro.c
for more infromation about these options), and do not notice any
decreased stability from doing so.

Moreover--admittedly with HZ=1000--despite running two make jobs in
the background, using KDE usually seems as if there isn't anything
running in the background at all (this is on a Pentium D).

In the interest of ultimately using clock-pro as the default page
replacement policy, I am asking anyone who has a [non-production] box
and would like to experiment with this to please enable
PDPOLICY_CLOCKPRO in their kernel (with and/or without the ADAPTIVE
and USEONCE2 defined), posting feedback to current-users.  My
subjective evaluation is clearly not enough, and I only have an amd64
box and so cannot run the haskell regression tests.  In addition,
given my naivete on this subject relative to others out there, I'd
especially like those more familiar than I with kernel internals to
experiment with this.

AFAIK, the current "clock" page replacement policy is ~35 years old.
Age is not inherently bad, of course, but it seems that the
"state-of-the-art" is moving beyond it.

I encourage those looking for better interactive performance on
non-production machines to try out PDPOLICY_CLOCKPRO, perhaps in
conjunction with BUFQ_PRIOCSCAN and finer clock rate.

Many thanks,

--Blair
-- 
Support WFMU-FM: free-form radio for the masses!

<http://www.wfmu.org/>
91.1 FM Jersey City, NJ
90.1 FM Mt. Hope, NY

"No matter where I treat my guests, they always like my kitchen best."