Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 May 2010 13:53:46 -0700
From:      Artem Belevich <fbsdlist@src.cx>
To:        Mike Andrews <mandrews@bit0.com>
Cc:        freebsd-stable@freebsd.org, Steve Polyack <korvus@comcast.net>
Subject:   Re: Freebsd 8.0 kmem map too small
Message-ID:  <x2ved91d4a81005101353u4320ede5p82d4669e6c04ea57@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1005101643490.30993@beast.int.bit0.com>
References:  <4BDEA86E.3050109@zirakzigil.org> <20100503110100.GA93137@icarus.home.lan> <4BDEC106.3040807@zirakzigil.org> <4BE110E3.8040902@zirakzigil.org> <q2vb269bc571005050819nde819098vfd3306170639a9c9@mail.gmail.com> <4BE82C5D.1080806@bit0.com> <4BE83B9B.5030209@comcast.net> <alpine.BSF.2.00.1005101643490.30993@beast.int.bit0.com>

next in thread | previous in thread | raw e-mail | index | archive | help
vm.kmem_size limitation has been this way for a pretty long time.

What's changed recently is that ZFS ARC now uses UMA for its memory
allocations. If I understand it correctly, this would make ARC's
memory use more efficient as allocated chunks will end up in a zone
tuned for allocations of particular size.

Increased fragmentation could be the side effect of this change, but
I'm guessing here.

--Artem



On Mon, May 10, 2010 at 1:45 PM, Mike Andrews <mandrews@bit0.com> wrote:
> On Mon, 10 May 2010, Steve Polyack wrote:
>
>> On 05/10/10 11:55, Mike Andrews wrote:
>>>
>>> On 5/5/10 11:19 AM, Freddie Cash wrote:
>>>>
>>>> On Tue, May 4, 2010 at 11:32 PM, Giulio Ferro<auryn@zirakzigil.org>
>>>> wrote:
>>>>
>>>>> Giulio Ferro wrote:
>>>>>
>>>>>> Thanks, I'll try these settings.
>>>>>>
>>>>>> I'll keep you posted.
>>>>>>
>>>>>
>>>>> Nope, it's happened again... Now I've tried to rise vm.kmem_size to
>>>>> 6G...
>>>>> I'm really astounded at how unstable zfs is, it's causing me a lot of
>>>>> problem.
>>>>> Why isn't it stated in the handbook that zfs isn't up to production
>>>>> yet?
>>>>>
>>>>
>>>> As with everything related to computers, it all depends on your uses.
>>>
>>> Sorry to semi-hijack this, but... =A0I'm also running into frequent
>>> "kmem_map too small" panics on 8-STABLE, such as:
>>>
>>> panic: kmem_malloc(131072): kmem_map too small: 2023780352 total
>>> allocated
>>> panic: kmem_malloc(131072): kmem_map too small: 2011525120 total
>>> allocated
>>> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total
>>> allocated
>>> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total
>>> allocated
>>> panic: kmem_malloc(114688): kmem_map too small: 1849356288 total
>>> allocated
>>> panic: kmem_malloc(131072): kmem_map too small: 2020409344 total
>>> allocated
>>> panic: kmem_malloc(536576): kmem_map too small: 2022957056 total
>>> allocated
>>>
>>> (those are over the course of 3-4 days)
>>>
>>> On this specific system, it has 32 GB physical memory and has
>>> vfs.zfs.arc_max=3D"2G" and vm.kmem_size=3D"64G" in /boot/loader.conf. =
=A0The
>>> latter was added per earlier suggestions on this list, but appears to b=
e
>>> ignored as "sysctl vm.kmem_size" returns about 2 GB (2172452864) anyway=
.
>>>
>>>
>> As Artem stated in another reply, you will need to set vm.kmem_size
>> slightly under 2x the physical memory. =A0The kernel will default to 2GB=
 if
>> you pass this limit. =A01.5x physical memory size should be sufficient, =
so try
>> "48G" and verify that it gets set correctly on the next boot.
>
>
> OK, I've got vm.kmem_size set a bit lower and it now accepts it. =A0It's =
still
> not clear why this just recently (April?) became necessary to do at all :=
)
>
> Meanwhile, I'll see if things get more stable now...
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x2ved91d4a81005101353u4320ede5p82d4669e6c04ea57>