Date: Sun, 24 Jun 2001 00:26:00 -0500 From: Andy Isaacson <adi@hexapodia.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <20010624002600.B31710@hexapodia.org> In-Reply-To: <XFMail.010623224452.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Sat, Jun 23, 2001 at 10:44:52PM -0700 References: <20010623214226.H67164-100000@scribble.fsn.hu> <XFMail.010623224452.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.) -andy 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?20010624002600.B31710>