From owner-freebsd-stable@FreeBSD.ORG Sun Sep 14 22:48:13 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F49C16A4BF for ; Sun, 14 Sep 2003 22:48:13 -0700 (PDT) Received: from ns1.itga.com.au (ns1.itga.com.au [202.53.40.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1160F43FBF for ; Sun, 14 Sep 2003 22:48:12 -0700 (PDT) (envelope-from gnb@itga.com.au) Received: from lightning.itga.com.au (lightning.itga.com.au [192.168.71.20]) by ns1.itga.com.au (8.12.9/8.12.9) with ESMTP id h8F5m7h1044801; Mon, 15 Sep 2003 15:48:07 +1000 (EST) (envelope-from gnb@itga.com.au) Received: from lightning.itga.com.au (localhost [127.0.0.1]) by lightning.itga.com.au (8.9.3/8.9.3) with ESMTP id PAA05158; Mon, 15 Sep 2003 15:48:07 +1000 (EST) Message-Id: <200309150548.PAA05158@lightning.itga.com.au> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.4 From: Gregory Bond To: Irvine Short In-reply-to: Your message of Mon, 15 Sep 2003 07:07:26 +0200. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 2003 15:48:07 +1000 Sender: gnb@itga.com.au cc: freebsd-stable@freebsd.org Subject: Re: Large memory issues on 4-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2003 05:48:13 -0000 > However we have a situation where if I set MAXDSIZ to 2048 or above then > things break, so FreeBSD right now has an effectivce limit of 2GB per > process. > > Is this to be considered a bug or a feature? It orta work above 2Gb, and has been known to work to about 3Gb. The fact that tcsh is reporting "unlimited" is probably a bug in tcsh (signed vs unsigned). But you can't put a limit on how much above 2Gb will definitely work, because the kernel's demand for VM space is variable, depending on hardware config, job mix & current activity. (The Kernel uses VM space for various data structures, but the ones that matter most in large RAM machines are the processes VM page tables etc.) So a given MAXDSIZE might work most of the time but fail in interesting ways when things get hot. And failing due to out of VM space is not handled very gracefully at all. If you're lucky you'll get a panic..... > Then, with the PAE support, lets say I have 8GB of RAM. Will those same > design limitations restrict me to 3GB of RAM, or 2GB, or will I be able to > have a single process addressing 4GB all by itself? No, the architectural limit is that the kernel and the user program share the one 32-bit address space, and the kernel typically needs up to 1Gb of it, so no user process can be bigger than this 3 Gb (or so) limit. So PAE will not help at all here (and in fact may make it worse as PAE data structures may be large than normal ones.) But with PAE you could have 2 or 3 of these large processes all RAM-resident at once, if you are willing to buy that much RAM. Fixing this is basically not going to happen; 64bit CPUs will be standard way before a project of that magnitude would be finished. Greg, not really a kernel hacker.