From owner-cvs-src@FreeBSD.ORG Sun Mar 30 12:04:54 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 385DD37B401; Sun, 30 Mar 2003 12:04:54 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29CFB43FAF; Sun, 30 Mar 2003 12:04:53 -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 h2UKBExS033592; Sun, 30 Mar 2003 15:11:14 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h2UKBEYI033591; Sun, 30 Mar 2003 15:11:14 -0500 (EST) Date: Sun, 30 Mar 2003 15:11:13 -0500 From: Jake Burkholder To: Mike Silbersack Message-ID: <20030330201113.GA32298@locore.ca> References: <200303300524.h2U5Ora7061852@repoman.freebsd.org> <20030330061301.GC21973@locore.ca> <20030330070723.GE21973@locore.ca> <20030330012410.I3292@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030330012410.I3292@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 20:04:56 -0000 Apparently, On Sun, Mar 30, 2003 at 01:31:18AM -0600, Mike Silbersack said words to the effect of; > > On Sun, 30 Mar 2003, Jake Burkholder wrote: > > > To clarify that the ram above 4G is used for, it just goes into the general > > page pool. I don't intend to implement a means for user process's to access > > more then their ~2.5G address space through a sliding window as has been done > > on other systems, but this should be quite easy to do should someone be so > > inclined. To give an example, on a 6G system you see things like this: > > Cool, that's much better than the situation was for large ram machines > before. :) > > 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. > > Also, I'm assuming that PAE can boot on machines with < 4 Gig of ram; can Yes, you can use PAE on small memory machines. This will at least give you compiler warnings about truncating physical addresses in most cases. > it also be coaxed into acting in such a manner than busdma is _required_, > so that a 256MB i386 box can be used to see if a driver is busdma > compliant? Not really. The best way is to buy a sparc :). I suppose that you could create your dma tags such that busdma thinks it needs to bounce, this would at least test that you've got the right bus_dmamap_syncs. ie set lowaddr to below the highest physical address in your machine. > > In any case, very cool. Thanks! Jake