>  [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.

Probably it is really hard to tell which kind of strategy is right for
Replecment, LRU
will be the most fair on overall --- I think. But probably not for
interactive Issues.
It is just a thought that came up, how about mesuring the activity on
the vnode
paging (caching) and other paging activity and then adjusting the factor
of how much
memory is used for caching as a maximum. This should adjust the cache
size in
respect to other memory loads. In doubt I would stick just to the LRU
approximation.

Lars

P.S.: I forgot to put linefeeds in the bug-report (kern/11636), Sorry.