panic: kmem_malloc(131072): kmem_map too small (AMD64)
Larry Rosenman
ler at lerctr.org
Mon Sep 24 08:32:25 PDT 2007
On Mon, 24 Sep 2007, Scott Long wrote:
> 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.
>
How can I help, and what's a proposed patch?
LER
> Scott
>
>
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler at lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
More information about the freebsd-current
mailing list