> I don't think this is the right answer.  if the only solution to the problem
> is to limit the amount of data used to cache file data, then people can only
> have good interactive response if they limit themselves to a tiny amount of
> cached data.

I don't think you understood what he said:

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

Note that the total cache size would be the minimal value PLUS whatever's
not being used by the in-core processes. That could be quite large!

As long as dormant processes get paged/swapped out, this should lead to
pretty sensible behavior since it means that any memory you're not actually
using is made available to the buffer cache.

But if you fill the machine with programs, it falls back to something that
should perform about as well as the old fixed-size buffer cache.

> we should be able to have good performance with a larger cache,
> and this should be the default.

If UBC uses all memory not otherwise needed for in-core processes then
that is good performance with a larger cache, is it not?

The solution is not to limit the maximum size of the UBC, but instead to
lower its priority when it already owns enough pages to get reasonable
performance.

If we need to be more aggressive about swapping out processes to make
room for UBC, then let's do that. But it's really stupid to have UBC
kick out any process that is likely to run in the next few seconds.

Todd Whitesel
toddpw @ best.com