Date: 25 Jun 2001 20:12:24 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Andy Isaacson <adi@hexapodia.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <xzp7ky0cttj.fsf@flood.ping.uio.no> In-Reply-To: <XFMail.010625121654.jhb@FreeBSD.org> References: <XFMail.010625121654.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@FreeBSD.org> 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. BTW, apps only get to enjoy 3 GB of their 4 GB address space, since we use a flat memory model where the kernel occupies the remaining space. DES -- Dag-Erling Smorgrav - des@ofug.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?xzp7ky0cttj.fsf>