From owner-cvs-src@FreeBSD.ORG Sun Mar 30 15:14:13 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCAA237B401; Sun, 30 Mar 2003 15:14:13 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73C9243F93; Sun, 30 Mar 2003 15:14:12 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h2UNKVxS034376; Sun, 30 Mar 2003 18:20:31 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h2UNKVvm034375; Sun, 30 Mar 2003 18:20:31 -0500 (EST) Date: Sun, 30 Mar 2003 18:20:30 -0500 From: Jake Burkholder To: Mike Silbersack Message-ID: <20030330232030.GB32298@locore.ca> References: <200303300524.h2U5Ora7061852@repoman.freebsd.org> <20030330061301.GC21973@locore.ca> <20030330070723.GE21973@locore.ca> <20030330012410.I3292@odysseus.silby.com> <20030330201113.GA32298@locore.ca> <20030330152920.D6586@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030330152920.D6586@odysseus.silby.com> User-Agent: Mutt/1.4i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: HEADS UP Re: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 bios.c locore.s machdep.c mpboot.s pmap.c vm86bios.s vm_machdep.c src/sys/i386/include _types.h bus_at386.h param.h pmap. X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 23:14:17 -0000 Apparently, On Sun, Mar 30, 2003 at 03:30:52PM -0600, Mike Silbersack said words to the effect of; > > On Sun, 30 Mar 2003, Jake Burkholder wrote: > > > > Do these changes allow something like a 3G KVA space without shrinking > > > processes address spaces? > > > > No, it doesn't make the virtual address space any bigger, it just allows > > more physical memory. This is a bit of a problem because the tunables that > > are based on physical memory size don't scale well past 4G of ram, its easy > > to end up with may too many vnodes. > > Is it practically possible with PAE and busdma'd drivers that such a > configuration could work? I'm not sure I understand the question, you mean is it possible to use separate address spaces for the kernel and userland, giving a full 4G each? Yes it is possible, but it is not practical. It would be prohibitively expensive and ugly. For example you would need to use task gates for system calls, and copyin or copyout would need to look up the user pages and map them temporarily, something like that. Keep in mind that the restriction is what can be mapped. It is still possible to keep around huge amounts of memory as long as its not all mapped all the time. For example many device drivers just do dma and don't need a virtual mapping for every chunk of memory they see, avoiding mapping and unmapping it would save a lot of KVA. Jake