From owner-freebsd-current@FreeBSD.ORG Thu Jun 26 12:47:35 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7399137B401; Thu, 26 Jun 2003 12:47:35 -0700 (PDT) Received: from redux.oneway.com (redux.oneway.com [216.22.46.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A3B43FE9; Thu, 26 Jun 2003 12:47:34 -0700 (PDT) (envelope-from jay@oneway.com) Received: from redux.oneway.com (localhost [127.0.0.1]) by redux.oneway.com (8.12.5/8.12.5) with ESMTP id h5QJkn4m038713; Thu, 26 Jun 2003 15:46:53 -0400 (EDT) Received: from localhost (jay@localhost)h5QJknOu038710; Thu, 26 Jun 2003 15:46:49 -0400 (EDT) X-Authentication-Warning: redux.oneway.com: jay owned process doing -bs Date: Thu, 26 Jun 2003 15:46:49 -0400 (EDT) From: Jay Kuri To: Terry Lambert In-Reply-To: <3EFAA595.1B019A95@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Schultz cc: freebsd-current@FreeBSD.ORG Subject: Re: questions about VM_KMEM_SIZE_SCALE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 19:47:35 -0000 Thank you both very much. This fills in the gaps nicely and I think I have a pretty good grip on this now. I feel like I can tune it a bit without worry now. (and avoid those nasty panics. :-) ) Thank you very very much. Jay On Thu, 26 Jun 2003, Terry Lambert wrote: > David Schultz wrote: > > On Tue, Jun 24, 2003, Jay Kuri wrote: > > > Does changing this affect memory available to user programs if it's unused > > > by the kernel? > > > > No, KVA_PAGES affects the memory available to user programs. (You > > have a 4 GB address space on i386 to split between user programs > > and the kernel.) Within the kernel's share of this address space, > > memory is split into submaps, such as the mb_map (for the > > network), buffer_map for the filesystem buffer cache, and the > > kmem_map for just about everything else. These submaps are > > size-limited to prevent any one of them from getting out of hand. > > > > The vm_kmem_map is sized automatically based on the amount of > > memory you have. Specifically, > > > > kmem_map_size = min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), > > VM_KMEM_SIZE_MAX) > > > > The default value for VM_KMEM_SIZE_SCALE is 3, and the default > > VM_KMEM_SIZE_MAX is 200MB. > > David is exactly right in what he has said. Some minor ommisions > about the implications of what he has said, though, are: > > 1) The intent of doing this is to ensure that, for a given > amount of physical memory, you don't grab more than > 1/VM_KMEM_SIZE_SCALE * 100 % of it (default: 50%) for > the kmem_map. > > 2) If you *need* a much larger kmem_map, you are limited to > 200K, no matter how much physical memory you have, unless > you raise VM_KMEM_SIZE_MAX, as well. > > 3) If you want to explicitly control the memory size, you can > set VM_KMEM_SIZE_SCALE very, very large, which will cause > the second term in the "max()" expression to approach zero, > and then set VM_KMEM_SIZE_MAX = VM_KMEM_SIZE = > to disable the "min()" expression. > > 4) The kmem_map is used to allocate kernel structure having to > do with memory management; if you have a very large amount > of memory in your system, you should consider increasing > VM_KMEM_SIZE_MAX, at a minimum, but realize that you are > competing for KVA with all ather uses of kernel memory, so > if your KVA space is 2G, and you have 4G of RAM, and your > VM_KMEM_SIZE_SCALE is 2 and you set VM_KMEM_SIZE_MAX so it > doesn't clamp the top end, you can run yourself out of KVA > space. IMO, it would be good to use something like > min(Physical Memory, KVA space) in place of Physical Memory > as the first term of the min() expression. > > 5) It's generally useful to set VM_KMEM_SIZE_MAX huge, and > then use only VM_KMEM_SIZE_SCALE to adjust how much of > the physical RAM you allow the kmem_map to use (subject to > the limits in #4, above). > > 6) Physical memory allocated to backing KVA resident maps > like kmem_map don't reduce the amount of virtual memory > available to user space processes; however, actually using > the full KVA space worth of physical memory might mean that > user space processes compete for physical RAM where they > wouldn't before, and so it may mean swapping. Memory in > KVA maps is generally type-stable and can't be reclaimed > for user process use (i.e.: the kernel does not page, except > for speciall allocated memory sections, and they are not > generally used for anything important enough to get a map > entry). > > -- Terry > - - - - - - - - - - - - - - - - - - - - - - - - - - - Nothing fails like success because you do not learn anything from it. The only thing we ever learn from is failure. Success only confirms our superstitions. Jay Kuri jay@oneway.com