From owner-cvs-all Mon Jun 25 14:46:59 2001 Delivered-To: cvs-all@freebsd.org Received: from pirx.hexapodia.org (pirx.hexapodia.org [208.42.114.113]) by hub.freebsd.org (Postfix) with ESMTP id E3D4137B409; Mon, 25 Jun 2001 14:46:54 -0700 (PDT) (envelope-from adi@hexapodia.org) Received: by pirx.hexapodia.org (Postfix, from userid 22448) id CCE82B404; Mon, 25 Jun 2001 16:46:53 -0500 (CDT) Date: Mon, 25 Jun 2001 16:46:53 -0500 From: Andy Isaacson To: Dag-Erling Smorgrav Cc: John Baldwin , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <20010625164653.B12871@hexapodia.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Mon, Jun 25, 2001 at 08:12:24PM +0200 X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-PGP-Key-URL: http://web.hexapodia.org/~adi/pgp.txt Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 25, 2001 at 08:12:24PM +0200, Dag-Erling Smorgrav wrote: > John Baldwin writes: > > Err, no. :) The process only sees 4gb of space. Period. The address that > > gets sent to the MMU before the page table lookups (but after the segment > > translation) is 32bits. Not 36, just 32. You can't make a 32-bit address > > acccess more than 4 gig of virtual address space, that's just all there is > > to it. > > I think Andy's point is that the kernel could take advantage of the > additional memory to cache a larger portion of the data set, even if > the app weren't able to access it all at the same time. The app would > do just what it would normally do with such a large dataset, i.e. map > bits of it in and out of its address space (using mmap() and munmap()) > preferably on some sort of LRU basis - business as usual - but the > kernel would be able to keep at least some of what doesn't fit in the > app's address space in memory. Precisely. Interestingly, in my tests on IRIX (the only machine I have access to with enough memory to test these concepts) my test app spends much (27%) of its time in the kernel. Since I was using 512-MB segments, I was probably exceeding the per-node memory on the O2k in question and making the kernel copy pages out of remote memory (or else it was spending all its time handling page table updates); furthermore, on such a machine I should just compile "cc -64" and be done with it. -andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message