kern/53350: fill up a malloc md-disk on 5.1-R causes panic

Jason Kuri jay at oneway.com
Sun Jun 15 10:40:13 PDT 2003


The following reply was made to PR kern/53350; it has been noted by GNATS.

From: Jason Kuri <jay at oneway.com>
To: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: kern/53350: fill up a malloc md-disk on 5.1-R causes panic 
Date: Sun, 15 Jun 2003 12:35:02 -0500

 Adding ram is not an option, as we need to be able to run this on 
 different machines with different configs.
 
 Is there a way to determine at run-time how much kernel mapped memory 
 is available for use?  I have determined that adding -o reserve will 
 cause the initial mdconfig to fail if the space is not available...  Is 
 there any documentation anywhere on the issues related to kernel mapped 
 memory and allocation?
 
 Is this tunable at run time, and if not, can you point me to some 
 information on how to properly use VM_KMEM_SIZE_SCALE (which I'm 
 assuming is the right option) ?
 
 And one final question, am I right in thinking that increasing this 
 will make less memory available for user processes even if the space is 
 unused by the kernel?
 
 Thanks,
 
 Jay
 
 On Sunday, June 15, 2003, at 11:56  AM, Poul-Henning Kamp wrote:
 
 > In message <A228C296-9F51-11D7-B102-00039398BAE0 at oneway.com>, Jason 
 > Kuri writes
 > :
 >> Ok, so speaking practically, how do I deal with this issue?  I have a
 >> script that needs to be able to cache directories in ram...
 >
 > You add more RAM or change the fraction of RAM assigned to KVM.
 > I can't remember if this is documented somewhere.
 >
 > mdconfig(8) would have a hard time being able to tell when to reject
 > a request, and for testing purposes, it is a very convenient thing
 > to be able to create 1TB devices (and this works, as long as you
 > don't fill it with more data than you have KVM to).
 >
 > -- 
 > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 > phk at FreeBSD.ORG         | TCP/IP since RFC 956
 > FreeBSD committer       | BSD since 4.3-tahoe
 > Never attribute to malice what can adequately be explained by 
 > incompetence.
 >
 


More information about the freebsd-bugs mailing list