On Sat, Mar 25, 2006 at 09:05:49AM -0500, yancm@sdf.lonestar.org wrote:
> This question is somewhat related to:
>     http://mail-index.netbsd.org/tech-net/2006/03/24/0010.html
> 
> I have a NetBSD 2.1_Stable (tools/userland and kernel) i386 system
> with 256M of physical ram w/256M of swap.
> 
> I'm using ipf which grabs memory from the kernel VM pool (I state that
> like I know what I'm talking about, but I may be abstracting behavior
> rather than understanding details...).
> 
> In order to increase available memory for large ipf rule sets,
> I have been increasing the kernel pool by tuning:
> options NKMEMPAGES=98352  #~196M
> in my kernel config file.
> 
> This has helped up to a point. But...
> 
> Q1: How large can/should I set this as a percentage of physical ram?
> Does it matter?

You probably don't want to put this too close to physical RAM, but it
depends on what userland programs you're running. If you're using
this system as router, maybe you don't need much userland RAM,
so increasing it 224 or 240MB may work.

> 
> The problem I'm having is that I want to increase the number
> of ipf filter rules, but as I add more rules I can just watch as
> rule loading eats away at free memory until...
> 
> I get an error (from ipf?) that it cannot allocate memory and at that
> point the system grinds to a near or complete halt. Often I have
> to perform a hard reset! *****
> 
> Q2: Is there some way to prevent an in kernel process (ipf) from
> taking my free memory so low that it freezes my system?

Hum, no. This kernel process should limit itself. limits don't apply
to kernel processes.

> 
> I have also noticed that if I flush the filter rules (ipf -F a),
> the amount of free memory does not come back up.

Does ipf -D get it back ?

> 
> Q3: Is this normal behavior? If not, is this a kernel/memory management
> bug or more likely to be a problem in ipf? How can I help diagnose?

Yes, once the kernel runs out of memory, things start going bad; especially
when most memory is allocated to a single subsystem which isn't likely to
free it by itself.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--