8 ms·

Very interesting. Is there any book that you can recommend to learn about memory behaviour of a program in Linux? I am aware that the starting point is cache mi

Very interesting. Is there any book that you can recommend to learn about memory behaviour of a program in Linux? I am aware that the starting point is cache miss, page fault, but not sure where to go from there.

kouteiheika 2y ago
Sorry, everything I know about this comes from experience so there aren't any books I can recommend. (: Although I could probably recommend you a hands-on project/exercise to do: - Write a simple memory allocator in C/C++/Rust/Zig/any similar systems language using raw `mmap` and `munmap` syscalls (run "man 2 mmap" in your terminal for details). This is how fundamentally almost every program allocates memory on the lowest level (with some exceptions, but I'm not going to get into that). - Allocate a bunch of memory with your allocator without actually reading/writing from than memory and check the program's RSS, then write to it and check the RSS again. Try allocating more memory than you have RAM and see if it works. Run the program under `perf` and check the page faults counter - see how the page fault number changes if you a) never write to the memory you allocated, b) only write to a single byte per page, c) write to every byte you allocated, d) write twice to every byte you allocated. - Play around with the `madvise` syscall ("man 2 madvise"), in particular with `MADV_DONTNEED`. - Try `mmap`ing on a file on your disk. `mmap` it with multiple processes at the same time.
- iamcreasy 2y ago
  This is very helpful, Thank you! Is it correct to say memory behaviour of a program entirely depends on what/how the program allocates and its memory access pattern? Is there any hello world memory allocator out there? File system moves blocks to memory, and kernel access them as pages, and kernel also moves them back to disk(using file system) depending on memory pressure. Given this is ture, I am assuming, when studying memory behaviour, virtual memory setup is good enough to ignore file system level details initially - but at what point these details become important? For example, just as cache miss, I am assuming, it is also very expensive for file system(paired with underlying physical medium) to go out and gather non-contiguous blocks and put them together to respond to a file access request.
  - kouteiheika 2y ago
    > Is it correct to say memory behaviour of a program entirely depends on what/how the program allocates and its memory access pattern? Mostly yes, but also on the rest of the system. > Is there any hello world memory allocator out there? Yes. That's a naive mmap-based allocator. (: It's terribly inefficient (slow and wastes a ton of memory) but you could in theory hook it to any program and it will work. > virtual memory setup is good enough to ignore file system level details initially - but at what point these details become important? For the basics you can ignore swapping. In general you can probably ignore it altogether (RAM is cheap), unless you're studying memory mapped I/O. > I am assuming, it is also very expensive for file system(paired with underlying physical medium) to go out and gather non-contiguous blocks and put them together to respond to a file access request. Data in memory is accessed in pages (so reading one byte will bring it the whole page). Data on disk is also stored in pages (although they might be a different size than the page size of your CPU). So what happens is roughly that the kernel will read a page you've hit from the disk and map it into your memory, and then probably read more data in the background while giving you the control back.

kouteiheika 2y ago

Sorry, everything I know about this comes from experience so there aren't any books I can recommend. (: Although I could probably recommend you a hands-on project/exercise to do: - Write a simple memory allocator in C/C++/Rust/Zig/any similar systems language using raw `mmap` and `munmap` syscalls (run "man 2 mmap" in your terminal for details). This is how fundamentally almost every program allocates memory on the lowest level (with some exceptions, but I'm not going to get into that). - Allocate a bunch of memory with your allocator without actually reading/writing from than memory and check the program's RSS, then write to it and check the RSS again. Try allocating more memory than you have RAM and see if it works. Run the program under `perf` and check the page faults counter - see how the page fault number changes if you a) never write to the memory you allocated, b) only write to a single byte per page, c) write to every byte you allocated, d) write twice to every byte you allocated. - Play around with the `madvise` syscall ("man 2 madvise"), in particular with `MADV_DONTNEED`. - Try `mmap`ing on a file on your disk. `mmap` it with multiple processes at the same time.

iamcreasy 2y ago
This is very helpful, Thank you! Is it correct to say memory behaviour of a program entirely depends on what/how the program allocates and its memory access pattern? Is there any hello world memory allocator out there? File system moves blocks to memory, and kernel access them as pages, and kernel also moves them back to disk(using file system) depending on memory pressure. Given this is ture, I am assuming, when studying memory behaviour, virtual memory setup is good enough to ignore file system level details initially - but at what point these details become important? For example, just as cache miss, I am assuming, it is also very expensive for file system(paired with underlying physical medium) to go out and gather non-contiguous blocks and put them together to respond to a file access request.
- kouteiheika 2y ago
  > Is it correct to say memory behaviour of a program entirely depends on what/how the program allocates and its memory access pattern? Mostly yes, but also on the rest of the system. > Is there any hello world memory allocator out there? Yes. That's a naive mmap-based allocator. (: It's terribly inefficient (slow and wastes a ton of memory) but you could in theory hook it to any program and it will work. > virtual memory setup is good enough to ignore file system level details initially - but at what point these details become important? For the basics you can ignore swapping. In general you can probably ignore it altogether (RAM is cheap), unless you're studying memory mapped I/O. > I am assuming, it is also very expensive for file system(paired with underlying physical medium) to go out and gather non-contiguous blocks and put them together to respond to a file access request. Data in memory is accessed in pages (so reading one byte will bring it the whole page). Data on disk is also stored in pages (although they might be a different size than the page size of your CPU). So what happens is roughly that the kernel will read a page you've hit from the disk and map it into your memory, and then probably read more data in the background while giving you the control back.