Subject: Re: failing to keep a process from swapping
To: Julio M. Merino Vidal <jmmv@menta.net>
From: Arto Selonen <arto@selonen.org>
List: tech-kern
Date: 10/22/2004 18:37:08
Hi!

On Fri, 22 Oct 2004, Julio M. Merino Vidal wrote:

> Since I set:
>
> vm.filemin=2
> vm.filemax=4
>
> in my /etc/sysctl.conf file, my two boxes hardly swap.  All other values set to
> defaults.

Although I appreciate the data point, I doubt if merely reducing
vm.filemax further would help. After all, it is already about 20
percentage points above the set maximum.

Before I try leaving all other settings to default, and just reducing
vm.file{min,max}, I would like to understand the logic behind the
reasoning that such a setup would actually improve my situation
(other than reducing the loose maximum file cache size from 150MB
down to 40MB).

My understanding from the 'Bad response' thread was that the maximums
would be exceeded only when there was memory to spare. Although
I don't remember if anybody ever stated that memory would be claimed
from those instances where the usage was above the given maximum,
that is how I've interpreted it. Thus, when 'squid' wants more
memory, it should not need to go to swap, as there is 200+ MB of
*excess* usage for file cache. Why not reduce file cache down towards
the given vm.filemax and give that to squid? If allocating memory
to file cache is a one way street (eg. once given, it will not be claimed
back in a timely manner), then I suppose vm.filemax should be a bit
harder limit.

What my problem boils down to, in general, is:

What specific steps do I need to take to be able to *guarantee*
that on a NetBSD-current a single process can grow above
50% available RAM size (eg. over 500 MB in a 1 GB system) without
pages of it ending in swap?

So far, I have failed to achieve that, against my expectations.
Until somebody argues otherwise, this failure could be the result
of my mistakes, me missing some specific setting, squid doing
something that "obviously" causes such behaviour *by design*,
a bug in the memory management, a lacking feature, or an efficient
memory management that knows better than me and already behaves
optimally. I'd like to know which one it is. :)


Artsi
-- 
#######======------  http://www.selonen.org/arto/  --------========########
Everstinkuja 5 B 35                               Don't mind doing it.
FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
Finland              tel +358 50 560 4826     Don't know anything about it.