Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Memory Management FAQ

landley.net

Post reply on HN
Print view View original

11–20 of 75 posts

Re: Linux Memory Management FAQ

#11

Post by littlestymaar »

dbattaglia wrote: post #4

"Virtual addresses are the size of a CPU register. On 32 bit systems each process has 4 gigabytes of virtual address space all to itself, which is often more memory than the system actually has." I guess this is not the most up-to-date document?

If you are thinking about the “which is often more memory than the system actually has" part, I don't know if it's outdated even today: the vast majority of Linux systems these days are Android phones, and I wouldn't be surprised at all if a good proportion of those didn't have more than 4GB of RAM.

Re: Linux Memory Management FAQ

#12

Post by db48x »

barnacled wrote: post #10
db48x wrote: post #8

Earlier quoted context omitted.

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.

In 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-…

True, 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.

Re: Linux Memory Management FAQ

#13

Post by barnacled »

db48x wrote: post #12
barnacled wrote: post #10

Earlier quoted context omitted.

In 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-…

True, 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.

Indeed, 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-n...

Re: Linux Memory Management FAQ

#14

Post by sigjuice »

db48x wrote: post #8
sigjuice wrote: post #6

Earlier quoted context omitted.

I think there might be some more hardware-specific nuance here. e.g. /proc/cpuinfo says this on a couple of different x86_64 systems that I checked. address sizes : 36 bits physical, 48 bits virtual address sizes : 40 bits physical, 48 bits virtual PS: I don't understand what this means, btw.

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.

So are the 16 leftmost bits of a virtual address always 0?

Re: Linux Memory Management FAQ

#15

Post by db48x »

barnacled wrote: post #13
db48x wrote: post #12

Earlier quoted context omitted.

True, 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.

Indeed, 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]…

You're not the only one dreaming; I had to use >200GB of swap on my home system last year.

Re: Linux Memory Management FAQ

#16

Post by barnacled »

sigjuice wrote: post #14
db48x wrote: post #8

Earlier quoted context omitted.

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.

So are the 16 leftmost bits of a virtual address always 0?

They 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/maste...

Re: Linux Memory Management FAQ

#17

Post by amscanne »

sigjuice wrote: post #14
db48x wrote: post #8

Earlier quoted context omitted.

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.

So are the 16 leftmost bits of a virtual address always 0?

No, it must be sign-extended from the top bit of the valid set. Otherwise the address is non-canonical.

Re: Linux Memory Management FAQ

#18

Post by db48x »

sigjuice wrote: post #14
db48x wrote: post #8

Earlier quoted context omitted.

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.

So are the 16 leftmost bits of a virtual address always 0?

Oddly enough the unused bits are in the middle of the address. They're also sign-extended rather than filled with zeros, so sometimes they are ones and other times they are zeros.

Re: Linux Memory Management FAQ

#19

Post by Agingcoder »

phtrivier wrote: post #7

The Drepper series of article dates from 2007. Is it still relevant or has anything fundamental changed in memory handling in the last 13 years ?

It's still relevant.

Other than that, I also think that even when outdated, computing history is worth reading anyway, since it gives you a natural understanding of _why_ we do what we do these days. In your day job, it also gives you a different appreciation for what people did and why they did it, and why 'this horrible code' may have made sense at the time.

Furthermore, performance engineering is fundamentally about opposing code and hardware limitations. If hardware limitations are different, you'll get different code, but the principles remain the same.

If you're curious, write a basic emulator for older hardware (the NES is a great choice) , it's both fun and eye-opening!

Edit: the NES emulator will answer 'how do you fit super mario bros in 32k, and how can it run on such limited hardware?'

Post reply on HN