Re: process max virtual memory limit in amd64?
> pointers are 64bits on AMD64. It's just that the top 16bits are all zero,
> until AMD makes CPUs that do something with them. Only the kernel will have
> to change to accommodate that, though. User-space programs won't have to be
> re-compiled. So, code is already leaving space for the extra bits, and
> transmitting them over the bus. No savings there, just stuff inside the CPU
> that deals with addresses, as others have described.
Just so that people aren't confused, I'll clarify a bit on what I
think Peter is saying. Virtual addresses are all 64-bits, so when a
pointer is stored in memory or read from memory, it still travels as
64-bits on the data lines of the memory bus. Software doesn't see the
little hardware tricks that are used to save on transistors and
interconnects/traces.
As far as the physical addresses sent on the address lines of the
memory bus, their width is a hardware implementation detail that is
abstracted away from software. Unless you are monkeying with kernel
code that manipulates the MMU, you probably cannot even write tests to
determine the width of the physical addresses used by your MMU and
sent on the address lines of your memory bus.
In any case, Peter's statements are correct, but could be easily
misinterpreted to mean that physical addresses are 64-bits (or longer,
if you take into account that the low-order log2(data_bus_width) bits
of the physical address are not sent on the address bus).
Are all of the high-order n bits of virtual addresses unused? I seem
to remember a lecture about the UltraSparc CPUs using the high-order
bit of virtual addresses, followed by n unused bits, followed by
(63-n) bits that are used. In this way, the kernel can be loaded at
0x8000000000000000, and that will never be equivalent to 0x0. This
means that the Solaris kernel needs no modification when Sun increases
the number of bits in virtual addresses that get used (decreasing n,
the number of bits that are ignored.) I would assume AMD64 CPUs use
the same strategy, but I have not read enough documentation.
-Karl
Reply to: