Re: kmem_map auto-sizing and size dependencies

看板FB_current作者時間12年前 (2013/04/27 13:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串7/7 (看更多)
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. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
文章代碼(AID): #1HUrkvXl (FB_current)
討論串 (同標題文章)
文章代碼(AID): #1HUrkvXl (FB_current)