Ruslan Ermilov wrote: > On Sat, Sep 22, 2007 at 11:37:37PM +0200, Kris Kennaway wrote: >> Darren Reed wrote: >>> Kris Kennaway wrote: >>>> Larry Rosenman wrote: >>>>> On Fri, 21 Sep 2007, Kris Kennaway wrote: >>>>> >>>>>> Larry Rosenman wrote: >>>>>>> I'm a heavy ZFS user, and got the following panic on 2007-09-18 >>>>>>> source/world: >>>>>> This is a FAQ, please see the archives (you need to increase the >>>>>> vm.kmem_size to provide more memory to ZFS). >>>>> I thought that was only for i386, and it hadn't been an issue before. >>>> Nope. It is also load-dependent. >>> So I just received this courtesy of ZFS: >>> panic: kmem_malloc(131072): kmem_map too small: 343027712 total allocated >>> cpuid = 0 >>> KDB: enter: panic >>> This was with these settings in loader.conf: >>> vm.kmem_size=419430400 >>> vm.kmem_size_max=419430400 > > Setting both doesn't make sense; kmem_size will take over. > kmem_size_max only limits the automatically computed value > of kmem_size, which is: > > /* > * How many physical pages per KVA page allocated. > * min(max(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), > * VM_KMEM_SIZE_MIN), VM_KMEM_SIZE_MAX) > * is the total KVA space allocated for kmem_map. > */ > >>> vfs.zfs.arc_max=409715200 >>> (That's 400M, 400M and 40M, respectively.) >>> 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. KrisReceived on Mon Sep 24 2007 - 08:07:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC