So I've tried running a kernel with PDPOLICY_CLOCKPRO for about a
week now and thought I'd post my impressions.  I'm a desktop NetBSD
user, using a 2GHz dual-core laptop with 1GB of RAM.  My work is
generally Java development in Eclipse using the Linux JDK, some
compilation of stuff in pkgsrc, web & e-mail and LaTeX/PDF commenting.
And occasional bittorrent.

Having skimmed the Usenix paper, the lure of never touching a tuning
parameter again was such an attraction that I my first kernel used
PDPOLICY_CLOCKPRO and ADAPTIVE (kernel #1).  I compiled a kernel
in the background, ran Eclipse using the Linux Sun JDK 1.5, some
Firefox windows, and ran several xterms while doing some LaTeX
work.  I found that the performance degraded pretty quickly.  From
watching top(1), it seemed like the file cache filled up very
quickly and yet emptied very slowly.  When swapping apps back in,
it looked like the system preferred swapping out other process
pages so as to maximize the file cache.  When I finally gave up on
this kernel, the file cache was 590M (my total RAM is 1GB).  It
did not feel good.  That said, it did feel like my Eclipse was
paged in a bit faster than normal; under a normal kernel once
Eclipse has been swapped out, the swap in can feels like forever.

I then tried a second kernel but with neither ADAPTIVE nor USEONCE32.
This time instead of compiling a kernel, I compiled the Sun SCSL
JDK 1.5.0 distribution in the background while also running Eclipse
and doing LaTeX work.  It felt better initially, but the file cache
grew, though seemingly a bit more slowly, and eventually consumed
720M.  From a suggestion from Blair, I tried changing the coldwaterpct
to 20, but it didn't seem to make a difference.  Switching to apps
that had been swapped out was painful: sluggish to an extreme.
Even an hour after the compile was finished, there was still 681MB
tied up in the file cache.

As my laptop doesn't support ACPI suspend-to-RAM under NetBSD, I
have to shutdown my laptop when moving locations.  I have continued
running kernel #2 since then, with the coldwaterpct at the default
10%.  It feels fine -- like a normal kernel using my hand-tuned
vm.* sysctls.  In the past couple of days, I've been doing a few
compiles and working with Eclipse, and it feels ok.  The file cache
has sometimes grown to 600M, but I've had memory free and so it
hasn't seemed to be a problem.  Except one point I fired up a
bittorrent app, the file cache ballooned, and apps were swapped
out, with subsequent sluggishness like I described above.

I realized while writing this that a normal NetBSD kernel without
any tuned vm.* sysctls also slurps up enormous amounts of file
cache and generally feels like kernel #1.  Kernel #2 actually feels
like a normal kernel with hand-tuned vm.* sysctls, with the exception
of the file-cache-ballooning.

So my verdict so far is that PDPOLICY_CLOCKPRO is much better than
the defaults with the normal NetBSD kernel, though it still doesn't
beat a tuned normal NetBSD kernel. 

I'll try boosting the vm.coldtargetpct higher and see what effect
that has.

Brian.

-- 
  Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
      "Amusement to an observing mind is study." - Benjamin Disraeli