Date: Tue, 22 Jan 2013 19:54:04 -0500 From: Adam McDougall <mcdouga9@egr.msu.edu> To: freebsd-current@freebsd.org Subject: Re: kmem_map auto-sizing and size dependencies Message-ID: <50FF34AC.9000204@egr.msu.edu> In-Reply-To: <CAFqOu6jO1iMM=gS5-x%2B_91JfCF3zdLW-Dfnvja2QozDWUV%2BkTA@mail.gmail.com> References: <50F96A67.9080203@freebsd.org> <CAMBSHm-xPo7bH556h4QwtHhCUHX%2B4g_pv3=t29C1SLD4VnBWsQ@mail.gmail.com> <20130121210645.GC1341@garage.freebsd.pl> <CAFqOu6jO1iMM=gS5-x%2B_91JfCF3zdLW-Dfnvja2QozDWUV%2BkTA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/22/2013 6:22 PM, Artem Belevich wrote: > On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote: >> On Fri, Jan 18, 2013 at 08:26:04AM -0800, mdf@FreeBSD.org wrote: >>>> Should it be set to a larger initial value based on min(physical,KVM) space >>>> available? >>> It needs to be smaller than the physical space, [...] >> Or larger, as the address space can get fragmented and you might not be >> able to allocate memory even if you have physical pages available. > +1 for relaxing upper limit. > > I routinely patch all my systems that use ZFS to allow kmem_map size > to be larger than physical memory. Otherwise on a system where most of > RAM goes towards ZFS ARC I used to eventually run into dreaded > kmem_map too small panic. > > --Artem > _______________________________________________ Ever since related code has been patched to properly permit kmem=2x physmem out of the box, I've been using that guideline for my systems and I've not had an out of kmem panic in years. I've previously ran into weird temporary deadlocks with strong IO if I set the kmem too high, as if the ARC caused something important to be overwritten; that is just my theory. I agree with the fragmentation principle here. YMMV regarding the kmem size.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50FF34AC.9000204>