4 ms·
Your CPU can handle 39-bit physical memory addresses (up to 512 GB of physical memory), and 48-bit virtual addresses (256 TB). Your operating system maintains a
by db48x 6y ago
Your CPU can handle 39-bit physical memory addresses (up to 512 GB of physical memory), and 48-bit virtual addresses (256 TB). Your operating system maintains a mapping from virtual to physical addresses, usually arranging the map so that every process has a separate memory space. Pointers are all still 64 bits long though.
- barnacled 6y agoIn practice the actual available usable address space for userland is 64 TiB due to user/kernel split and the kernel maintaining a virtual mapping of the entire physical address space (minus I/O ranges) [0]. However newer incoming 5-level page intel chips [1] will allow up to 57 bits of address space, 128 PiB in theory though in practice 32 PiB of userland memory. See also [0] for discussion on practical limit for 5-page too! [0]:https://github.com/lorenzo-stoakes/linux-mm-notes/blob/master/virt_layout.md#available-address-space https://github.com/lorenzo-stoakes/linux-mm-notes/blob/maste... [1]:https://en.wikipedia.org/wiki/Intel_5-level_paging https://en.wikipedia.org/wiki/Intel_5-level_paging
- db48x 6y agoTrue, though /proc/cpuinfo only reports the size, which is ultimately what the CPU cares about. Plus the most relevant limit is what your motherboard and wallet supports, which is often far lower.
- barnacled 6y agoIndeed, and as you say, sensibly speaking you are hardly likely to hit those limits in any likely (esp. home) setup. The actual meaningful limit is usually the CPU physical one as home CPUs very often have stringent memory limits (often 32 GiB or so) and of course you rely on the motherboard's limitations also. Having said that I did write a patch to ensure that the system would boot correctly with 256 TiB of RAM [0] so perhaps I am not always a realist... or dream of the day I can own that system ;) [0]:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=167dcfc08b0b1f964ea95d410aa496fd78adf475 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
- db48x 6y agoYou're not the only one dreaming; I had to use >200GB of swap on my home system last year.
- sigjuice 6y agoSo are the 16 leftmost bits of a virtual address always 0?
- barnacled 6y agoThey have to be same as the maximum addressable bit, i.e. in the case of 48 bit virtual address size the 48th bit. This is actually kind of a cute way of dividing kernel and userland space as you just set the upper bit to 1 for kernel addresses and 0 for userland. EDIT: Specifically talking about x86-64 here. https://github.com/lorenzo-stoakes/linux-mm-notes/blob/master/virt_layout.md#virtual-address-layout https://github.com/lorenzo-stoakes/linux-mm-notes/blob/maste...
- amscanne 6y agoNo, it must be sign-extended from the top bit of the valid set. Otherwise the address is non-canonical.
- xxpor 6y agoThis is true for x86-64, not true for other architectures such as arm64. Apple uses the high bits to cryptographicly sign the pointer value.
- everybodyknows 6y agoFascinating. Does this confer some of the benefits of ECC RAM, for pointer data only — without the hardware cost?
- danielheath 6y agoSome (but I believe the advantage is that it’s much harder to inject valid code from a buffer overflow).
- saagarjha 6y agoPAC is more about CFI than preventing shellcode injection (which is done through codesigning and memory protection, mostly).