From owner-freebsd-hackers Fri Dec 12 13:12:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA24868 for hackers-outgoing; Fri, 12 Dec 1997 13:12:05 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA24814 for ; Fri, 12 Dec 1997 13:11:49 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id QAA02732; Fri, 12 Dec 1997 16:11:38 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712122111.QAA02732@dyson.iquest.net> Subject: Re: Virtual Memory Question In-Reply-To: <199712121617.KAA06873@ns.tar.com> from "Richard Seaman, Jr." at "Dec 12, 97 10:17:02 am" To: lists@tar.com Date: Fri, 12 Dec 1997 16:11:38 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Seaman, Jr. said: > If I allocate memory using either malloc or mmap, how do I know if the > address handle I get back can be mapped to physical backing of some > sort (RAM or swap)? > > For example, I have a machine with 16MB RAM and 64MB swap. Using > malloc, I can malloc just about 128MB. Obviously, thats more than I > can get physical backing for. Trying to access it all terminates > the process, as would be expected. > > For mmap (MAP_ANON with fd -1), I can "allocate" virtual memory totalling > over 3GB. Same problem. > > Or, am I just supposed to be smart enough to not grab too much memory? > FreeBSD allocates a VM object for large chunks of data, but does not reserve swap. The allocation is done to avoid internal deadlocks, but does not eliminate the possiblility of the ultimate one of running out of swap. I have an idea for a limited swap reservation system, that is not complex, and could be turned on by a sysctl. We might have something by 3.0. (The reason that it is not in there yet, is because alot of desktop systems run with swap space overcommitted, due to conservative (low) estimation of swap requirements. Those who really need the additional "security" of space reservation are usually also aware of swap space needs.) -- John dyson@freebsd.org jdyson@nc.com