the notion is that it's important to keep some percentage of pages
as VTEXT no matter what else it going on, but that percentage doesn't
need to be very big, something like 3% to 5% of RAM.  memory would
similarly be reserved for anonymous pages and for non-VTEXT vnode data.
the result would be that around 25% of RAM would be dedicated to one
of these specific uses, with the remaining 75% allocated to whatever
type of memory is needed most recently.   this will be tunable so that
administrators who want to dedicate more RAM to a given use will be able
to do so.

-Chuck


On Sat, Dec 02, 2000 at 10:24:18PM +0100, Sean Doran wrote:
> [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.