Re: KVA/KVM shortages
If you can get a kernel core, run vmstat -m on it to see what the state of the allocation hoppers was. -Matt Matthew Dillon :As no one seemed to comment directly on this I thouht I would relay our :experiances: : :panic: pmap_new_proc: u_map allocation failed : :Imediatly after the login promt appeared on the console:-( : :This was running UNI-proccessor with softupdates and ccd the application :is disk and network heavy, circa 300 processes, however most memory is :used as cache. : :This is 3.0-RELEASE with security fixes. : :-- :GeoffB : :To Unsubscribe: send mail to majord...@freebsd.org :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
Previously on Thu, Jan 21, 1999 at 06:09:41PM +, Geoff Buckingham wrote: : On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with : 768MB RAM) poking about in the code adding: : : options "VM_KMEM_SIZE=(24*1024*1024)" : options "VM_KMEM_SIZE_MAX=(128*1024*1024)" : : seems like a good way foward. Is it? : As no one seemed to comment directly on this I thouht I would relay our experiances: panic: pmap_new_proc: u_map allocation failed Imediatly after the login promt appeared on the console:-( This was running UNI-proccessor with softupdates and ccd the application is disk and network heavy, circa 300 processes, however most memory is used as cache. This is 3.0-RELEASE with security fixes. -- GeoffB To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
Previously on Thu, Jan 21, 1999 at 01:53:44PM -0800, Mike Smith wrote: : > On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with : > 768MB RAM) poking about in the code adding: : > : > options "VM_KMEM_SIZE=(24*1024*1024)" : > options "VM_KMEM_SIZE_MAX=(128*1024*1024)" : > : > seems like a good way foward. Is it? : : >From what I can see, you shouldn't need to set VM_KMEM_SIZE_MAX unless : you're also setting VM_KMEM_SIZE_SCALE. : My understanding was VM_KMEM_SIZE_SCALE picks up a default of value of 3 from vmparam.h, which if I understand the following from kern-malloc.c vm_kmem_size = VM_KMEM_SIZE; mem_size = cnt.v_page_count * PAGE_SIZE; #if defined(VM_KMEM_SIZE_SCALE) if ((mem_size / VM_KMEM_SIZE_SCALE) > vm_kmem_size) vm_kmem_size = mem_size / VM_KMEM_SIZE_SCALE; #endif #if defined(VM_KMEM_SIZE_MAX) if (vm_kmem_size >= VM_KMEM_SIZE_MAX) vm_kmem_size = VM_KMEM_SIZE_MAX; #endif combined with the apparent defaults of VM_KMEM_SIZE 12M VM_KMEM_SIZE_SCALE 3 VM_KMEM_SIZE_MAX 80M means vm_kmem_size never gets bigger than 80M without VM_KMEM_SIZE_MAX being defined >80M (This is all from a mid december 3.x box) : I just committed a tweak that allows you to say: : : set kern.vm.kmem.size= : : at the loader prompt or in /boot/loader.rc to override the default : VM_KMEM_SIZE value. : Unless I am being too literal or miss-understanding the above do you not need to set VM_KMEM_SIZE_MAX or have thing moved on since december? -- GeoffB To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
Mike Smith writes: > I just committed a tweak that allows you to say: > > set kern.vm.kmem.size= > > at the loader prompt or in /boot/loader.rc to override the default > VM_KMEM_SIZE value. > > If anyone has any more of these tunables that can easily be enhanced > like this, please let me know. > How about all the parameters that are assigned in param.c? Why not make them all tweakable in the loader.rc, rather than having to patch the kernel. Actually, thinking about this a little more ... The loader knows where all symbols are in memory. Why not a general mechanism to let you reassign the value of any "variable" used in the kernel or in a module. I presume that the loader allocates bss for the kernel and each module as it loads it. So I presume I can assign a value to a variable that would ordinarily take on a 0 value, too. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
> Mike Smith writes: > > > I just committed a tweak that allows you to say: > > > > set kern.vm.kmem.size= > > > > at the loader prompt or in /boot/loader.rc to override the default > > VM_KMEM_SIZE value. > > > > If anyone has any more of these tunables that can easily be enhanced > > like this, please let me know. > > > How about all the parameters that are assigned in param.c? Why not > make them all tweakable in the loader.rc, rather than having to patch > the kernel. Because they're not all used in fashions that either make tuning them really desirable, or easy. I looked at all of them and decided that most weren't actually really candidates for that sort of hackery. > Actually, thinking about this a little more ... > The loader knows where all symbols are in memory. Why not a general > mechanism to let you reassign the value of any "variable" used in > the kernel or in a module. I presume that the loader allocates bss > for the kernel and each module as it loads it. So I presume I can > assign a value to a variable that would ordinarily take on a 0 > value, too. Because most of them are initialised at runtime from preprocessor defines, so tweaking their initial values wouldn't save anything (you'd have to hack the code anyway to have it not override a non-zero initial value). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
> > > >If anyone has any more of these tunables that can easily be enhanced > >like this, please let me know. > >Is there a way from the boot loader that one can find out what options > are available to be tuned? At the moment, the values are picked up on-demand by the kernel as it's initialising its state from the preprocessor defines, so there's no metainformation that can be extracted from the kernel to determine the tunables that are available. This could be improved in a number of ways - it would be achievable, for example, to have a macro: is_set = GET_KERN_TUNABLE(name, "description", variable); which exported "name" and "description" via a linker set which could be extracted by the loader. In the meantime, "help set tunables" inside the loader contains a list of the ones I've updated so far (the source for this is in sys/boot/common/help.common) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
>> On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with >> 768MB RAM) poking about in the code adding: >> >> options "VM_KMEM_SIZE=(24*1024*1024)" >> options "VM_KMEM_SIZE_MAX=(128*1024*1024)" >> >> seems like a good way foward. Is it? > >>From what I can see, you shouldn't need to set VM_KMEM_SIZE_MAX unless >you're also setting VM_KMEM_SIZE_SCALE. > >I just committed a tweak that allows you to say: > > set kern.vm.kmem.size= > >at the loader prompt or in /boot/loader.rc to override the default >VM_KMEM_SIZE value. > >If anyone has any more of these tunables that can easily be enhanced >like this, please let me know. Is there a way from the boot loader that one can find out what options are available to be tuned? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
> On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with > 768MB RAM) poking about in the code adding: > > options "VM_KMEM_SIZE=(24*1024*1024)" > options "VM_KMEM_SIZE_MAX=(128*1024*1024)" > > seems like a good way foward. Is it? >From what I can see, you shouldn't need to set VM_KMEM_SIZE_MAX unless you're also setting VM_KMEM_SIZE_SCALE. I just committed a tweak that allows you to say: set kern.vm.kmem.size= at the loader prompt or in /boot/loader.rc to override the default VM_KMEM_SIZE value. If anyone has any more of these tunables that can easily be enhanced like this, please let me know. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
KVA/KVM shortages
On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with 768MB RAM) poking about in the code adding: options "VM_KMEM_SIZE=(24*1024*1024)" options "VM_KMEM_SIZE_MAX=(128*1024*1024)" seems like a good way foward. Is it? -- GeoffB To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
