Date: Thu, 31 Jan 2013 10:32:09 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: alc@FreeBSD.org Cc: Alan Cox <alan.l.cox@gmail.com>, freebsd-arch@FreeBSD.org Subject: Re: kva size on amd64 Message-ID: <510A2C09.6030709@FreeBSD.org> In-Reply-To: <CAJUyCcOvHXauk76LnahQPGmdcHbkDOiR1_=4w%2BDW=sZ6i6EJ%2BA@mail.gmail.com> References: <507E7E59.8060201@FreeBSD.org> <51098743.2050603@FreeBSD.org> <CAJUyCcOvHXauk76LnahQPGmdcHbkDOiR1_=4w%2BDW=sZ6i6EJ%2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 31/01/2013 10:10 Alan Cox said the following: > In short, it will waste a non-trivial amount of physical memory. Unlike user > virtual address spaces, page table pages are preallocated for the kernel virtual > address space. More precisely, they are preallocated for the reserved (or > defined) regions of the kernel map, i.e., every range of addresses that has a > corresponding vm_map_entry. The kmem map is one such reserved region. So, if > you always set your kmem map to its maximum possible size of ~300GB, then you > are preallocating about 600MB of physical memory for page table pages that will > never be used (except on machines with 300+ GB of DRAM). Alan, thank you very much for this information! Would it make sense then to do either of the following: - add some (non-trivial) code to auto-grow kmem map upon kva shortage - set default vm_kmem_size to min(2 * mem_size, vm_kmem_size_max) ? Perhaps something else?.. BTW, it seems that in OpenSolaris they do not limit kva size, but probably they allocate kernel page tables in some different way (on demand perhaps). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510A2C09.6030709>