On Tue, Apr 03, 2001 at 05:48:05PM -0000, eeh@netbsd.org wrote:
> 
> 	I'd probably preferred if the buffer cache would not touch text&data
> 	pages at all. In other words, that buffer cache would only use
> 	free, otherwise unused memory. It seems highly suboptimal for the page
> 	scanner to kick processes' data/text pages out of memory just to make
> 	more room for i/o buffers.
> 
> There always seems to be some confusion here.  There is no `free, otherwise 
> unused memory' and the buffer cache guarantees that.

... and this is a good thing!  why have memory sitting around useless
when it could be storing a potentially useful piece of file data?


> Pre-UBC, the buffer cache had a dedicated set of pages, ISTR it was
> somewhere around 5% of RAM.  If the buffer cache needed a page it would
> have to evict another buffer cache entry.  If something else needed a
> page it would have to evict something other than a buffer cache page.
> In that configuration, you sometimes had free pages (above the free
> page requirement) because the buffer cache couldn't use them and either
> a large process terminated and freed them or nothing else needed them.

right, physical memory was partitioned into two sets, one used exclusively
for file data and the other used exclusively for things other than file data.
(this is a little over-simplified, but it's close enough.)


> With UBC, the buffer cache competes for pages with everything else.  
> And the buffer cache is always hungry.  Whenever you do an I/O operation
> the buffer cache will consume a page, and the buffer cache never frees
> pages the way exiting processes do.  They need to be stolen.  And (at
> least before Chuq's latest performance patch) all pages compete equally.
> Since the buffer cache is in use, those pages are more recent, thus less
> likely to be reclaimed than other pages that have not been used as recently.
> 
> 	I think there should be some minimal value of memory dedicated to
> 	buffer cache (i.e. what BUFCACHE/BUFPAGES does) and more memory
> 	would only be used if it's otherwise _unused at all_.
> 	Perhaps this might be an option, but such behaviour should be default IMHO.
> 
> That's pretty much what the patch I sent out some time ago does, but it
> limits the buffer cache to inactive limit.  You can always give it a try.

the problem with this is that the inactive limit isn't really tunable.
changing that would probably affect system behaviour in strange, unexpected
ways.  if we want to talk about an independent limit, that's a different
story.


> Chuq's performance patch, as I understand it, tries to insure the system
> retains a minimum number of pages of a specific type.  I prefer to try
> something that tries to predict the likelyhood of reuse rather than put
> restrictions on the number of pages of any particular type in use.

ok, what algorithm would you use to predict the likelihood of reuse?
no one has tried to justify one algorithm or another on this basis so far.


-Chuck