I've been noticing for a while that my 8MB pc532 has been getting slower
and slower.  An example is that under 1.5X it takes just over 4 hours to
compile a kernel, with 1.6K it's just over 10 hours.  This is with an
identical userland - only the kernel changed.

One benchmark I've been using to compiling pc532/machdep.c in
single-user mode.  For the various kernels I had lying around in /,
here's some times:

NetBSD 1.5X: avail mem 6220 KB  55.189u  20.468s  2:06.78 59.6% 0+0k 71+63io  5364pf+0w
NetBSD 1.6C: avail mem 6168 KB  56.360u 482.015s  9:38.15 93.1% 0+0k 75+61io 62491pf+1w
NetBSD 1.6D: avail mem 6168 KB  56.027u 488.959s  9:44.56 93.2% 0+0k 75+59io 63718pf+1w
NetBSD 1.6J: avail mem 6132 KB  56.829u 643.266s 12:26.71 93.7% 0+0k 71+63io 90841pf+1w
NetBSD 1.6K: avail mem 6092 KB  56.683u 219.568s 11:55.53 38.6% 0+0k 71+57io 82888pf+1w
NetBSD 1.6K: avail mem 6232 KB  56.567u 220.508s 10:25.33 44.3% 0+0k 66+59io 76750pf+1w

The last 1.6K kernel has NFS removed to try to bring the available
memory back to what it was around 1.5X.

At Jason's suggestion, I started playing with the ubc tunable
parameters.  After trying a couple of different combinations without
much gain, I just set all mins to 5% and all maxs to 10% - and the
compile speed returned back to what we were seeing in the 1.5X days.

Further analysis shows that it's pretty much just vm.anonmax that
affects things (for this particular benchmark).  Here's some timings
for various values of anonmax:

    vm.anonmax = 80 (default)
        56.499u 197.264s  9:38.60 43.8% 0+0k 0+55io 70259pf+1w
        56.595u 199.414s 11:03.29 38.5% 0+0k 0+56io 74919pf+1w
        56.325u 220.143s 11:06.18 41.4% 0+0k 0+54io 78995pf+1w

    vm.anonmax = 90
        55.232u  22.921s  2:11.07 59.6% 0+0k 0+54io  6877pf+1w
        55.491u  14.919s  1:45.78 66.5% 0+0k 0+55io  4000pf+1w
        55.509u  13.182s  1:39.96 68.7% 0+0k 0+66io  3307pf+1w

    vm.anonmax = 95
        55.647u   8.334s  1:27.26 73.3% 0+0k 0+56io  1797pf+1w
        55.735u   7.553s  1:22.23 76.9% 0+0k 0+54io  1408pf+1w
        55.795u   8.724s  1:26.39 74.6% 0+0k 0+54io  1926pf+1w

    vm.anonmax = 100
        55.642u   8.270s  1:24.14 75.9% 0+0k 0+65io  1612pf+1w
        55.534u   9.216s  1:27.40 74.0% 0+0k 0+64io  1927pf+1w
        55.312u   8.331s  1:24.15 75.6% 0+0k 0+64io  1604pf+1w

I'm running with vm.anonmax=95 now.

Now, the question is should we automatically tune vm.anonmax up high
for low-memory situations?  And what would qualify as a "low-memory"
situation?

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/