4 ms·

"Under no/low memory contention... With swap: We can choose to swap out rarely-used anonymous memory that may only be used during a small part of the process l

"Under no/low memory contention... With swap: We can choose to swap out rarely-used anonymous memory that may only be used during a small part of the process lifecycle, allowing us to use this memory to improve cache hit rate, or do other optimisations." How do you improve cache hit rate when there's no memory contention? And what other optimizations? "Without swap: We cannot swap out rarely-used anonymous memory, as it's locked in memory. While this may not immediately present as a problem, on some workloads this may represent a non-trivial drop in performance due to stale, anonymous pages taking space away from more important use." When there's no memory contention, what's the "more important use"? These are honest questions - I'm not an expert on the topic.

sgtnoodle 5y ago
I think the point is that, the more free RAM you have, the more data the OS can speculatively read from disk when there's otherwise unutilized bandwidth. If a program happens to need the data, then it's already in RAM and the access latency is almost zero, vs. the non-zero latency of waiting for a hard disk platter to spin around. The claim being made is that there are certain situations where processes allocate a lot of physical memory but then very rarely accesses it. If it gets paged out to swap, then there's a latency hit on the next access. If the OS can avoid more latency hits total using the same physical RAM for caching, then the computer could do more overall calculations per second.
- Sirened 5y ago
  Yep! The idea of "free memory" largely doesn't exist in modern operating systems. We haven't gotten to the point of power gating DRAMs (have we?), so we're always paying the cost of the DRAM all the time. As such, not using it means you're just throwing energy away. Keeping lots of purgeable data in these unallocated space like (as you said) disk cache not only speeds up access time but also saves a ton of power since a hit to DRAM is leagues lower than having to access external storage. While this is a non-trivial engineering problem, it's almost always a good trade off since it boost performance and saves power without any extra cost other than the effort of speculative loads (which, when linear, is much less expensive than a random one off load!) and managing it
ColonelPhantom 5y ago
By cache, I assume the writer means disk cache. Disks are slow! (Yes, even your PCIe 4.0 x4 NVMe SSD is.) So the kernel (usually) uses RAM to cache reads and writes. (This can be bypassed, but let's ignore that.) Under heavy disk IO, using fast RAM for this cache is more beneficial than reserving it on behalf of a program that may use it very rarely, or maybe even not at all (in the case of memory leaks)! If on a hypothetical 8GiB RAM system, programs require 6 but 2 of those are rarely used, there is no memory contention but the extra space for disk cache is still a helpful boost. I do think program memory is more valuable on most desktop systems, since commonly memory access is expected to be fast while disk access is expected to be slow. This means that interactive software tends to mitigate for slow IO, while it can't do much against being swapped out. On servers however I'd probably rather let the kernel do its job (at least if I'm focusing on throughput), unexpected slowness may worsen a worst case but the average case is helped enough. Luckily, the Linux kernel, for all of its memory management flaws (don't get me started on overcommit), allows configuring this using the vm.swappiness parameter that tells it what to prioritize.

sgtnoodle 5y ago

I think the point is that, the more free RAM you have, the more data the OS can speculatively read from disk when there's otherwise unutilized bandwidth. If a program happens to need the data, then it's already in RAM and the access latency is almost zero, vs. the non-zero latency of waiting for a hard disk platter to spin around. The claim being made is that there are certain situations where processes allocate a lot of physical memory but then very rarely accesses it. If it gets paged out to swap, then there's a latency hit on the next access. If the OS can avoid more latency hits total using the same physical RAM for caching, then the computer could do more overall calculations per second.

Sirened 5y ago
Yep! The idea of "free memory" largely doesn't exist in modern operating systems. We haven't gotten to the point of power gating DRAMs (have we?), so we're always paying the cost of the DRAM all the time. As such, not using it means you're just throwing energy away. Keeping lots of purgeable data in these unallocated space like (as you said) disk cache not only speeds up access time but also saves a ton of power since a hit to DRAM is leagues lower than having to access external storage. While this is a non-trivial engineering problem, it's almost always a good trade off since it boost performance and saves power without any extra cost other than the effort of speculative loads (which, when linear, is much less expensive than a random one off load!) and managing it

ColonelPhantom 5y ago

By cache, I assume the writer means disk cache. Disks are slow! (Yes, even your PCIe 4.0 x4 NVMe SSD is.) So the kernel (usually) uses RAM to cache reads and writes. (This can be bypassed, but let's ignore that.) Under heavy disk IO, using fast RAM for this cache is more beneficial than reserving it on behalf of a program that may use it very rarely, or maybe even not at all (in the case of memory leaks)! If on a hypothetical 8GiB RAM system, programs require 6 but 2 of those are rarely used, there is no memory contention but the extra space for disk cache is still a helpful boost. I do think program memory is more valuable on most desktop systems, since commonly memory access is expected to be fast while disk access is expected to be slow. This means that interactive software tends to mitigate for slow IO, while it can't do much against being swapped out. On servers however I'd probably rather let the kernel do its job (at least if I'm focusing on throughput), unexpected slowness may worsen a worst case but the average case is helped enough. Luckily, the Linux kernel, for all of its memory management flaws (don't get me started on overcommit), allows configuring this using the vm.swappiness parameter that tells it what to prioritize.