[ On Friday, August 27, 2004 at 11:20:14 (+0200), Johnny Billquist wrote: ]
> Subject: Bad response...

[[ "bad response" is a very bad subject line!  :-) ]]

> I think the system currently is very badly tuned by default.

you may be right, for some purposes, BUT...  ;-)

> But I know that people probably disagree with me, so I have just one 
> question: how do I limit the file cache to take no more than, say, 16 MB?
> No matter how much the system thinks it *might* be able to use.

I think the problem is that you're asking the wrong question and for the
wrong reasons.

You really do not likely want to limit the maximum amount of memory the
file cache, etc. can use, at least not if there's a better way.  Using
RAM for the file cache can help system performance enormously, if it's
done right.  Since the unified buffer cache NetBSD has been enormously
smarter about using the file cache smartly (even in 1.6).  Before the
unified buffer cache NetBSD was a complete dog at filesystem performance
-- worse even than really ancient Unix systems.  Now NetBSD shines as
one of the best (even without the help of softdep).

However I agree that it's _very_ bad to be forcing paging of program
text or data when a whole bunch of memory is "wasted" on file data,
especially if the system's main job is to run programs with their data
in memory, not to read and write lots of files all the time.  Note
though that such behaviour is only bad if it happens all the time.  It's
not bad at all if you've suddenly switched usage profiles from a
file-heavy one to a monster-app one.  Far too many (NetBSD) users
complain (far too loudly) about the sluggishness of switching and fail
to realize that it's the price they must pay for performance within a
particular usage profile.  If you want things to be snappy when you
switch usage profiles then you need to make sure your system has enough
memory to support both usage profiles simultaneously -- period.

What I think you want to do is make sure that the file cache _minimum_
size is quite low, perhaps lower than it is by default (on 1.6.x it's
10%, and I think 5% is much more reasonable, though for your purposes 1%
might be more than enough), so that it won't hold onto so many pages
if/when there's demand for "higher priority" memory (they should be one
of the first to go, but to do that you have to set the _minimum_ lower).

You also don't want the file cache to grab too much memory from other
uses whenever files are accessed.  The default vm.filemax is 50% and
that seems quite fair to me.  It might be good to raise vm.execmax
though (but it depends on your application's memory usage profile).

I think it might be nice if we could adjust the priorities between these
pools too so that on memory starved machines we can set all the vm.*max
settings high without worrying but still make sure the right right kind
wins in tight spots for the desired usage.  That may still require a
bunch of flushing and reclaiming and paging when usage patterns shift,
but I think it would give the best performance for the widest varieties
of usage, especially on what ammount to single "user" systems.  For
example on a production NFS server one might want the file cache to
"win" all of the time, but on a laptop one would want anon and exec
pages to "win" evenly over file every time yet if you want to move a
bunch of files around and/or search through them repeatedly on your
laptop then you could stop using programs that consume lots of exec and
anon pages and still have the benefit of using all the now unused memory
for the file cache and thus avoid having to pay the price of every I/O
going all the way out to your slow laptop drive every time.

Of course if one also wants to run big programs on that production NFS
server then one wants just those big, rare, programs to page and not any
of the other programs that have to run for the benefit of NFS and
related services and one certainly doesn't want them stealing too much
memory from the filecache on a busy NFS server either.  I've always
thought it might be nice to greatly extend and expand upon the old
"sticky bit" idea so that some kind of filesystem attributes could be
used to control the default priorities for certain programs such that
those priorities wouldn't have to be adjusted "manually" after every
time they've been started.  E.g. one could give programs like ntpd,
mountd, nfsd, etc. high memory priority on an NFS server but on a laptop
one could give high priority to whatever programs and shared libraries
one most commonly uses.  I.e. it would be nice to have some way to
prioritize memory use between different applications without having to
have them do it themselves and without having to poke at their PIDs
after they've been started but rather to provide that advice to the
kernel through static filesystem attributes on the files they are loaded
from.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>