Date: Mon, 9 May 2011 22:06:14 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Brad Waite <lists@wcubed.net> Cc: freebsd-amd64@freebsd.org Subject: Re: Understanding i386 PAE Message-ID: <20110509190614.GJ48734@deviant.kiev.zoral.com.ua> In-Reply-To: <4DC831AE.1070103@wcubed.net> References: <4DC816F4.1030406@wcubed.net> <201105091327.36809.jhb@freebsd.org> <4DC831AE.1070103@wcubed.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Z/W+H++SBmO57jII Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 12:25:50PM -0600, Brad Waite wrote: > On 5/9/2011 11:27 AM, John Baldwin wrote: >=20 > Thanks for the clarification, John. >=20 > > FreeBSD uses a shared address space on x86 (both i386 and amd64) where > > the kernel is mapped into every process' address space at a fixed addre= ss. =20 > > This makes it cheaper and easier to copy data between a user process an= d the=20 > > kernel since you don't have to temporarily map user pages into the kern= el's=20 > > address space, etc. >=20 > That's disappointing for my use, but it make sense. >=20 > > It is possible to use separate address spaces for the kernel and userla= nd=20 > > (other OS's have done this) so that you could have 4G for the kernel an= d 4G=20 > > for userland. However, this would require a good bit of work in the ke= rnel=20 > > (e.g. copyin/copyout would have to start mapping user pages at temporar= y=20 > > addresses in the kernel). >=20 > Would be handy to be able to use memory this way, but if I were > responsible for making it happen, I'm sure that we'd be on amd128 before > it was finished. ;) Jeff had patches that implemented this. Redhat did patched their kernel for some time, but finally decided not to do anymore. It is much more trouble then the gain on x86. >=20 > > As you have noted, PAE does not increase your virtual address space, me= rely=20 > > your physical address space by changing PTEs to use 64-bit physical add= resses=20 > > instead of 32-bit physical addresses. However, each process can only a= ddress=20 > > up to 4G of RAM at a time. >=20 > So given the shared address space, the amount of memory the kernel can > use doesn't benefit much from PAE. I can see how typical installs with > lots/big userland processes and the standard 1G KVA would benefit, > though. Since I'm trying to eke as much memory as I can for ZFS, I don't > gain much. >=20 > I suppose I could allocate 3.75G for the kernel, assuming that none of > my userland processes need more than .25G (or that if they do, swapping > to disk is okay). I am sure it will not even start init(8). Note that 250Mb is the _virtual address space_, and not the physical memory available to=20 the process. Well, init(8) is static, so it might start, but I am sure that e.g. sh(1) will not. Also, even if you allocate ~3GB for kernel KVA, the amount of space available for ZFS cache will be less then this, probably much less. Due to other kernel users for VA, and due to fragmentation. >=20 > Would that be pushing it? I've come across a few things about hardware > addresses eating up 256M - 512M of RAM - is that still the case with > PAE? If that is pushing it, what's the max KVA you'd recommend. First, you should indeed understand the difference between physical memory pages (which PAE allows to have large pool of) and virtual address space. After that, you would see clearly that what you are trying to do is mostly a waste. Esp. due to ZFS architecture of having directly addressed pages in the cache. UFS with page cache/buffers would use as much pages as provided for caching. --Z/W+H++SBmO57jII Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3IOyYACgkQC3+MBN1Mb4gVTgCfb5TUcubh2SuyVbzVVvu3pzwx qrkAn1s/Ltq9jqE04C/deV7vrWC0QvM1 =9Nq0 -----END PGP SIGNATURE----- --Z/W+H++SBmO57jII--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509190614.GJ48734>