Re: -CURRENT kernel panic

On Sun, 7 Mar 2004, Vincent Poy wrote:
> On Sun, 7 Mar 2004, Andre Guibert de Bruet wrote:
> > On Sat, 6 Mar 2004, Vincent Poy wrote:
> > >
> > > 	I managed to get the system not panicing on bootup if I set the
> > > VM_KMEM_SIZE_MAX to 384MB.  At 512MB and 768MB, it would panic but anyone
> > > knows what the default VM_KMEM_SIZE_MAX size is?
> >
> > That's the maximum amount of KMEM that your system can have. Let's say for
> > example that you have a system with 4GB of RAM. You set VM_KMEM_SIZE_MAX
> > to 1GB but VM_KMEM_SIZE_SCALE to 8 you get:
> >
> > VM_KMEM_SIZE_MAX: 1024 MB of KMEM
> > VM_KMEM_SIZE_SCALE: 512 MB of KMEM (4096/8)
> >
> > The algorithm uses the lesser of these two numbers. Remember that a whole
> > lot of things use the allocated memory so don't skimp! If you don't want
> > to use the memory in your system, take it out and set it on the desk. ;-)
>
> 	Okay, here's a dumb question.  If it uses the less of the two
> numbers, is there a reason to need to even define the VM_KMEM_SIZE_SCALE
> since wouldn't by default, it be 1/3rd of your RAM anyways?

The SCALE value is there to protect in the case of systems that might have
memory amounts that change. If you had a set value for your KMEM which is
larger than the amount of memory available when RAM is pulled out, your
kernel would surely not boot. For short, the SCALE value lets you get
creative with the size assigned to your KMEM.

You might find the following mail interesting:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2003-06/1599.html

> > I've found through personal experience and endless hours of experimenting
> > on fairly busy machines that the following values work for the various RAM
> > configurations (Lower values may also work depending upon disk, net and
> > load):
> >
> > RAM		KMEM size
> > 4.0GB		768MB
> > 3.5GB		768MB
> > 3.0GB		512MB
> > 2.5GB 		384MB
> > 2.0GB		384MB
> > 1.5GB and below	256MB
>
> 	You're right that anything above 384MB using a scale of 2, the
> kernel would panic as soon as the Real Memory is posted in the boot.  Did
> this problem actually exist recently because prior to February 28, I was
> on a September 26, 2003 -CURRENT and it has not had the problem.  I'm
> using maxusers=512 in the kernel as well as 65536 NMBCLUSTERS, it used to
> be 32768 but I thought that was what was causing the panic.

This problem has been around since at least June of last year, which is
the date that I first had a test system with more than 1GB running CURRENT
(All my production systems still track STABLE).

> > As with everything, backup your data, put on your fire-retarding suit, and
> > YMMV. :-)
>
> 	Nah, the kernel one doesn't require backing up the data since the
> only reason I get the panic is because I'm dumping both / and /usr to
> another identical drive.  It's only doing the /boot/loader.conf variable
> for kmem that's scary. ;)

Loader tunables for this type of thing scare me too. I guess we're just
old school...

Andy

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/    >