=> Perhaps we want a new "ubc_inactive" list, which isn't counted
=> in the inactive target?  And always include ubc_inactive in

That is sort of the way solaris folks went.  They have become
aware of the UBC related problems rather late in sol7 release
cycle and came up with the "priority paging" algorithm.

The gist of it was that they said "totaly Unified" [BC] is bad
to deal with, and they introduced two major "classes" of
pages: fs-cache and "the rest of it".

The cleaned exclusively fs-cache pages when free core-page
number was in zone A;

0    minfree       lotsfree               cachefree
|-------|--------------|-----------------------|---->  free pages,
 zone S      zone B              zone A                    N

They cleaned all pages when free core went down into zone B;
and they started aggressive process swap-out if free core was
consistantly (during some interval, say 30 secs) lower minfree
(zone S).

They also introduced some hacks for shared objects.  In order
to prevent stealing pages from extensively shared libraries,
they assign a "weight" (po_share, number of shares) to a
shared page and instead of swapping immediately just
decremented the weight of a page.  When weight goes down, the
page can be stolen (they also increment weight, if no pages
were stolen during the last clock-round).

These two things cry for generalisation: de-unification of
pages into "classes", and "weights" (or if you wish, policies)
for page classes.  Then pagedaemon code (and design ;)) will
become much cleaner and simpler while hopefully producing
better results and be more configurable (through, say,
/etc/system.conf or some such thing).

One last thing to mention is that I don't know the inner
workings of nbsd UVM (nor of solaris for that matter, I just
read Solaris Internals, that's all), so if I said something
really wrong -- my apologies.  But from following all of the
UBC + pmap discussions I got the feeling that the code "is"
complex and "the big picture" seems to escape most of us.
That is normally result of under-design and "hairy" code (too
much logic inside "if" conditions).

To sum up: IMHO, de-unification of pages, as suggested by
Jason, is a good thing but care should be taken while
designing it.  I'm personally not in favour of ubc_inactive
kind of solution (feels too specific-ky) but would rather
prefer to see more general approach.  Thanks,

-Evgeni