[lifted from current-users to tech-kern]

| I'm planning to change things to also track VTEXT vnode pages
| separately from anonymous pages and non-VTEXT vnode pages, which will
| hopefully resolve the issues with interactive latency. 

Tricky... consider a program which has a bunch of VTEXT pages it
may not reuse for a long time, that were necessary in initializing
a bunch of structures and the like for a program with a huge memory
pool which is managed by a mark-and-sweep or stop-and-copy gc mechanism,
oh, like emacs maybe.   The VTEXT pages that haven't been used recently
are less likely to be necessary than the stuff from the gc arena which
hasn't been used recently, and are more disposable, since, page-age
being equal, they are less likely to cause a program to page fault.

I don't think that old VTEXT pages are _automatically_ more interesting
to retain than old anonymous pages when we are optimizing for perceived
latency.  In fact, I would suggest that fairness-is-fairness works for us, 
and we should do a strict LRU(-approximation) across the entire cache.
If a degree of unfairness is desirable, weight the LRU by the containing
process's/processes' status, priority or nice value, or the page's
amount-of-page-sharing (e.g. cow), rather than by type.

	Sean.