Date: Mon, 26 Jul 2010 13:48:48 -0500 From: Alan Cox <alan.l.cox@gmail.com> To: Matthew Fleming <mdf356@gmail.com> Cc: Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: amd64: change VM_KMEM_SIZE_SCALE to 1? Message-ID: <AANLkTikSJKVqhn9CWfYDoniB=tGu3C9giekyr6orOO9Y@mail.gmail.com> In-Reply-To: <AANLkTikY%2BnPTgBtDWcphNkOrW-Aif5TRSCuCn8BsK3p7@mail.gmail.com> References: <4C4DB2B8.9080404@freebsd.org> <AANLkTikY%2BnPTgBtDWcphNkOrW-Aif5TRSCuCn8BsK3p7@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 26, 2010 at 12:04 PM, Matthew Fleming <mdf356@gmail.com> wrote: > On Mon, Jul 26, 2010 at 9:07 AM, Andriy Gapon <avg@freebsd.org> wrote: > > > > Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set > to 1? > > I mean things potentially breaking, or some unpleasant surprise for an > > administrator/user... > > As I understand it, it's merely a resource usage issue. amd64 needs > page table entries for the expected virtual address space, so allowing > more than e.g. 1/3 of physical memory means needing more PTEs. But > the memory overhead isn't all that large IIRC: each 4k physical memory > devoted to PTEs maps 512 4k virtual addresses, or 2MB, so e.g. it > takes about 4MB reserved as PTE pages to map 2GB of kernel virtual > address space. > > Having cut my OS teeth on AIX/PowerPC where virutal address space is > free and has no relation to the size of the hardware page table, the > FreeBSD architecture limiting the size of the kernel virtual space > seemed weird to me. However, since FreeBSD also does not page kernel > data to disk, there's a good reason to limit the size of the kernel's > virtual space, since that also limits the kernel's physical space. > > This last answer is the answer that I would give as well. As you say, the page table memory isn't that significant. > In other words, setting it to 1 could lead to the system being out of > memory but not trying to fail kernel malloc requests. I'm not > entirely sure this is a new problem since one could also chew through > physical memory with sub-page uma allocations as well on amd64. > > Yes, on both counts. However, many of the things that we might allocate with uma_small_alloc() have caps, e.g., vnode structures, mitigating the risk somewhat. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikSJKVqhn9CWfYDoniB=tGu3C9giekyr6orOO9Y>