On Fri, Jan 26, 2001 at 04:45:28PM -0000, eeh@netbsd.org wrote:
> 
> 	this problem with this approach is that it unbalances the system
> 	too much in favor of anonymous data.  if there is enough swap-backed
> 	data to fill the 2/3 of memory which we attempt to keep in the active queue,
> 	then vnodes will only have the 1/3 of memory in the inactive queue available
> 	to cache their data, which is silly if the anonymous memory is (eg.)
> 	netscape's in-memory cache and netscape has been iconified in the corner
> 	of the screen all day while the user has been trying to do some file-
> 	intensive work.
> 
> Chuck, that is precisely the behavor everyone is complaining
> about.  If you're running with a high I/O load that means you
> are working your way through pages at a high rate.  Both the 
> X server and X applications tend to be bursty in both CPU useage 
> and page useage since they execute based on user input.  If
> you're writing a document and stop to think for 20 seconds
> YOU DO NOT WANT YOUR X SERVER AND EDITOR SWAPPED OUT, which
> is what happens right now, even with all of the page scanner
> fixes.  
> 
> Sacrificing a few dozen pages of buffer cache for an 
> iconified in-memory netscape is precisely the trade you want
> to make on an interactive system.  The reason you iconify a
> program rather than terminate it so it gives up all its
> resources is that you want it to be instantly accessible.
> Being forced to page it all in is precisely what you don't
> want.

maybe we're talking about a different "netscape",
the one I'm talking about occupies a thousand pages,
not a couple dozen.


> 	I do agree that the paging algorithm does need to be enhanced,
> 	but this isn't the way to do it.    from subsequent mail on this list,
> 	it appears that people are already figuring out that part of the problem
> 	is a simple error on my part, but I haven't ready through all the rest
> 	of this week's tech-kern mail yet, so I'm not sure where things stand
> 	right now.
> 
> Priority  paging and buffer cache high water marks do the
> same thing as putting UBC pages directly on the inactive
> list, but are more complex and less adaptive.

priority paging and buffer cache high water marks are more complex
but they are also more adaptive, since the idea is that the thresholds
will be configurable.  if you want to limit the buffer cache to 30% of
memory, then you can set the threshold there and it will behave exactly
they way you want.  I don't want to set it that way, though.

the configurable threshold stuff isn't there yet, but it will be.

-Chuck