Date: Fri, 28 Jun 2013 11:41:32 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Chris Torek <torek@mail.torek.net> Cc: freebsd-hackers@freebsd.org Subject: Re: expanding amd64 past the 1TB limit Message-ID: <20130628084132.GM91021@kib.kiev.ua> In-Reply-To: <201306272123.r5RLNapo064878@elf.torek.net> References: <51CBED22.6090702@freebsd.org> <201306272123.r5RLNapo064878@elf.torek.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--2gpokFnphsYkgNXa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2013 at 03:23:36PM -0600, Chris Torek wrote: > OK, I wasted :-) way too much time, but here's a text file that > can be comment-ified or stored somewhere alongside the code or > whatever... I think it would be a nice addition to the VM article in the doc collection. The content is correct and useful, IMO. See some notes below. > The reason for having those "empty" (all-zero) PTE pages is that > whenever new processes are created, in pmap_pinit(), they have > their (new) L4 PTE page set up to point to the *same* physical > pages that the kernel is using. Thus, if the kernel creates or > destroys any level-3-or-below mapping by writing into any of the > above four pages, that mapping is also created/destroyed in all > processes. Similarly, the NDMPML4 pages starting at DMPDPphys are > mapped identically in all processes. The kernel can therefore > "borrow" a user pmap at any time, i.e., there's no need to adjust > the CPU's CR4 on entry to the kernel. It is %cr3. >=20 > (If we used bcopy() to copy the kernel pmap's NKPML4E and NDMPML4E > entries into the new pmap, the L3 pages would not have to be > physically contiguous, but the KVA ones would still all have to > exist. It's free to allocate physically contiguous pages here > anyway though.) I do not see how the physical continuity of the allocated page table pages is relevant there. Copying the L4 or L3 PTEs would cause serious complications. In fact, this is how i386 operates, since due to limited VA, pmap does not have a luxurly of allocating entire L(top-1) page table pages to the kernel. As result, pmap_kenter_pde() have to iterate over the whole pmap list, which is maintained just to be able to update KVA mappings. >=20 > So, the last NKPML4E slots in KPML4phys point to the following > page tables, which use all of L3, L2, and L1 style PTEs. (Note > that we did not need any L1 PTEs for the direct map, which always > uses 2MB or 1GB super-pages.) This is not quite true. In the initial state, indeed all PTEs for direct map are superpages, either 1G or 2M. But Intel states that a situation when the physical page has mappings with different caching modes causes undefined behaviour. As result, if a page is remapped with non-write back caching attributes, the direct map has to demote the superpage and adjust the mapping attribute of the page frame for the page. As result, it is possible to have small mappings in the direct map. See pmap_page_set_memattr(), which delegates the work to pmap_change_attr(_locked). --2gpokFnphsYkgNXa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRzUw7AAoJEJDCuSvBvK1B/dgP/iEyZew3Kh9QRcyNjHQe/XE+ u9dHpKoCLNsAFXJJqTLXZcaNiSQCsABjC8fgyaA4ruUZw/3xUyffAWML0MMAfJe5 GKsQpV6cxjO9RHh4xrXi62lf87/G7If7ltcKnmwEfLzqBmPt77Wu2qiV2RIF32mK 8QyggtfEX9RIU1hIfsOmvuRiwyp9Z8GOvSrXEPI6ngzTWbSfxulHNzkzi+9Hd1qj hmG5emune641WQ/zcwka0gNWlivyOskioeujRdVszPM9EawZEVcwOTcrNiV7SbuF B6+q+G4LNgbh4kmAb2R2N3Z4diS9K/V1r13M+QCK0POgZ5/wu7vv+uPjVYKT3G3T 2PFnq8d8WfYSEfxcVHDdyGdPxoYXlBdRqO5vAtDhjYlfteC6LqOeIZIrwSksH5cg 9LFC/qmvwRUygkLk2J3qe+f7ZgqnN1956dj604HlLl97EjA62e5kd251wv+MP8vf Bpy90XGHleimkkI3wn+ikZAzZMxQMEgxKxUVBNcjYwXdf2pGYYQ6F8DNYxACqAlq HvYLDucrY0NJOq3olc22Y23SNlOu3I/Ly0YFrs/BEzhMOzjUxLHSk4u4tYsdrgRj CBDH5GUEVVvLOoNoT1w+q8xeEqBjt7RJoo1QwVQt0hJTG61xq4eOMTKsmJ7KPh5E Rwoe17b0pKrPW6tbtmsW =xV7w -----END PGP SIGNATURE----- --2gpokFnphsYkgNXa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130628084132.GM91021>