From owner-cvs-all Mon Jun 25 10:43:34 2001 Delivered-To: cvs-all@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 56CCA37B406; Mon, 25 Jun 2001 10:43:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f5PHh3I18467; Mon, 25 Jun 2001 10:43:05 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010624002600.B31710@hexapodia.org> Date: Mon, 25 Jun 2001 12:16:54 -0700 (PDT) From: John Baldwin To: Andy Isaacson Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org 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 24-Jun-01 Andy Isaacson wrote: > [What is this doing on cvs-all? Oh well, I wouldn't have seen it if > it were in the right place.] > > On Sat, Jun 23, 2001 at 10:44:52PM -0700, John Baldwin wrote: >> On 23-Jun-01 Attila Nagy wrote: >> > Hello, >> >> > Hmm- can you have more than 4GB of memory on an i386? >> >> Yes, you can have up to 64gb on PPro's or later (at least, the CPU's >> >> support a 36-bit physical address space) but we don't currently >> >> support the extensions so we can't use more than 4 anyways. >> > Do you plan to support this feature in the future (for example in 5.0)? >> >> It's not easy. >> >> > I think it's not too easy and not an obvious task, but maybe it's worth >> > the extra work (people using big DBs on x86?)... >> >> Actually, it doesn't really help as much as it would seem, because the >> virtual >> address space of each process is still limited to 4gb, so it doesn't let you >> run larger processes, it just lets you fit more of them into memory. > > Ah, but assuming all the necessary kernel support, I can arrange my > database as multiple 2GB segments, and access them as mmaped files. > munmap() + mmap() should be pretty efficient, assuming the kernel does > everything right, and the data never needs to hit disk. (Yes, this is a > horrid hack, and the right solution is to use a 64-bit processor, but > what can you do.) 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. The only way you could possibly get away with this would be to use multiple address space mappings for a single process, which would require special syscalls that allowed the app to switch address spaces. (We can't autodetect a fault and switch address spaces because, once again, the process can only access 4gb of space.) That would be a gross, gross hack that would be very x86 specific and not worth the effort. > -andy -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message