From owner-freebsd-hackers Fri Dec 6 1: 6:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5AEC37B401; Fri, 6 Dec 2002 01:06:44 -0800 (PST) Received: from apache.metrocom.ru (www.metrocom.ru [195.5.128.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 742F543E4A; Fri, 6 Dec 2002 01:06:43 -0800 (PST) (envelope-from alex@metrocom.ru) Received: from apache.metrocom.ru (localhost [127.0.0.1]) by apache.metrocom.ru (8.12.6/8.12.6) with ESMTP id gB692a1I000992; Fri, 6 Dec 2002 12:06:41 +0300 (MSK) Received: from localhost (alex@localhost) by apache.metrocom.ru (8.12.3/8.12.3/Submit) with ESMTP id gB5EQXS6022723; Thu, 5 Dec 2002 17:26:33 +0300 (MSK) X-Authentication-Warning: apache.metrocom.ru: alex owned process doing -bs Date: Thu, 5 Dec 2002 17:26:33 +0300 (MSK) From: Varshavchick Alexander To: David Schultz Cc: Terry Lambert , , Subject: Re: maxusers and random system freezes In-Reply-To: <20021205135319.GA12456@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Dec 2002, David Schultz wrote: > In FreeBSD, each process has a unique 4G virtual address space > associated with it. Not every virtual page in every address space > has to be associated with real memory. Most pages can be pushed > out to disk when there isn't enough free RAM, and unallocated > parts of the virtual address space aren't backed by anything. > (Referencing an unmapped page that the system doesn't know about > generally causes the program or OS to crash. You've probably seen > these as ``segmentation faults'' and ``page fault in kernel mode'' > panics.) > > To simplify things, the kernel is mapped into a fixed location in > every address space. The KVA parameter controls how big a chunk > the kernel gets; the remainder goes to user processes. However, > only the part of the KVA reservation that the kernel actually uses > is wired to physical memory. For example, if you have a 1 GB KVA > reservation and the kernel allocates only 20 MB of RAM, then only > 20 MB of RAM is needed (plus some epsilon if you want to be > picky), but in theory, the kernel could allocate and manage up to > 1 GB of data. You don't lose extra physical memory for increasing > KVA, but a large KVA size does constrain the virtual address space > available to user processes. > Thank you David for such an excellent explanation. So if sysctl reports vm.zone_kmem_pages: 5413 vm.zone_kmem_kvaspace: 218808320 vm.kvm_size: 1065353216 vm.kvm_free: 58720256 does it mean that total KVA reservation is 1065353216 bytes (1G) and almost all of it is really mapped to physical memory because only 58720256 (56M) is free, and the server is balancing on the edge of crashing with KVA going out? ---- Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message