AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080128170308.16051830@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<ed.kwan@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E07FB4FDD@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 28 Jan 2008 17:04:04 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Ed Kwan" <ed.kwan@onstor.com>
Subject: Re: Please review bsd compile option change
Message-ID: <20080128170404.41a9db16@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E07FB4FDD@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E07FB4FDD@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 28 Jan 2008 14:41:47 -0800 "Ed Kwan" <ed.kwan@onstor.com> wrote:

> Hi Andy,
>=20
> This is for the BSD compile option change that I mentioned a week or
> 2 ago.  It's to increase the kmem_map from the default 4MB to 16 MB.
> From the OpenBSD options(4) man page:
>=20
>      option NKMEMCLUSTERS=3Dvalue
>      Size of kernel malloc area in CLBYTES-sized logical pages.  This
> area is covered by the kernel submap kmem_map.
> See /usr/include/machine/param.h for the default value, which is port
> specific.  Increase this value if =E2out of space in kmem_map=E2
>=20
> The change number is 27485.
>=20
> Thanks,
> Ed
>=20
> =3D=3D=3D=3D //depot/dev/openbsd/src/sys/arch/pmonmips/conf/BOBCAT#1
> - /homes/edk/p4/dev/openbsd/src/sys/arch/pmonmips/conf/BOBCAT =3D=3D=3D=3D
> 150a151,153
> >
> > # Increase kmem_map from the default 4MB to 16MB.
> > option NKMEMCLUSTERS=3D4096

OK, it's coming back to me a little bit.  Has this proven to solve any
problem(s) that we are having?  I'm worried about what effect this
change will have on other problems in the memory area but not in this
area, like user space processes wanting large amounts of memory.  I'm
also thinking about a large variety of configurations and what effect
this might have on some configuration(s) that currently work but might
be perturbed by this w/o our knowing.  Until we get a case #.  OK, so I
guess those are really the same thing.  We only have 256MiB - 48MiB to
begin with....

Did you run this one by Max?  He might have some latent knowledge of
the effect of increasing this.
