Re: panic: kmem_malloc(131072): kmem_map too small (AMD64)

Ruslan Ermilov wrote:
> On Mon, Sep 24, 2007 at 08:04:33AM -0500, Larry Rosenman wrote:
>> On Mon, 24 Sep 2007, Kris Kennaway wrote:
>>
>>> Ruslan Ermilov wrote:
>>>> On Sat, Sep 22, 2007 at 11:37:37PM +0200, Kris Kennaway wrote:
>>>>> Darren Reed wrote:
> [...]
>>>>>> Stupid question, perhaps, but is vm.kmem_size/vm.kmem_size_max limited 
>>>>>> by physical RAM?
>>>>> Yes.
>>>> To be precise, it's actually limited by 2 * sizeof(physical RAM).
>>>> It's still size of a _virtual_ memory map (kmem_map), after all:
>>>> :	/*
>>>> : 	 * Limit kmem virtual size to twice the physical memory.
>>>> : 	 * This allows for kmem map sparseness, but limits the size
>>>> : 	 * to something sane. Be careful to not overflow the 32bit
>>>> : 	 * ints while doing the check.
>>>> : 	 */
>>>> : 	if (((vm_kmem_size / 2) / PAGE_SIZE) > cnt.v_page_count)
>>>> : 		vm_kmem_size = 2 * cnt.v_page_count * PAGE_SIZE;
>>> Well OK, but that seems pretty dangerous, because it leaves open a pathway 
>>> to exhaust all of physical memory and presumably panic.
>> is KVA pageable?  Is the kmem_map dedicating non-pageable memory?
>>
> kmem_map is used to map memory for the zone allocator, including
> malloc(9).
> 
>> I've set my vm.kmem_max to 1G, (on a 4G amd64 box).  Is that reasonable?
>>
> It just means that your kernel can "malloc" up to 1G of memory.
> 

You're all missing the point, I hate to say.  What happened is that a 
change was made recently to more accurately account for allocated
memory.  Now people are getting kmem_map_too_small panics that weren't
getting them before.  So while the accounting is now more accurate, the
outcome is actually harmful.  That needs to be fixed before the release.

Scott