Date: Mon, 25 Jun 2001 12:16:54 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Andy Isaacson <adi@hexapodia.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <XFMail.010625121654.jhb@FreeBSD.org> In-Reply-To: <20010624002600.B31710@hexapodia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010625121654.jhb>