Hacker News Reader

Comment by perl4ever | Hacker News Reader

"VM pressure, measured in the amount of address space not resident in primary memory"

Ok, question from someone clueless without recent low-level programming experience - is this in fact a normal situation on modern systems?

Because I had the general impression that exactly because the gulf between storage and memory speeds has widened so much, that virtual memory is more of a historical appendix than anything.

My laptop has 8 GB of memory, which I think is fairly small these days, so how likely is it that I would be using approaching but less than 8MB more - between 100% and 100.01% of my memory?

...I went and looked for the date of this article, and it's almost 10 years old, so perhaps things have changed...

View on HN

Everyone here saying paging is uncommon on modern systems with large RAM is correct, but there is another factor. TLB misses are expensive and since they involved MMU misses their effect is pretty analogous to paging. So slowdowns still exist but they're not quite as pronounced since each miss only costs you a few main memory accesses rather than going all the way to secondary storage. They do happen rather more often than paging though due to the small size of the TLB.

From https://en.wikipedia.org/wiki/Translation_lookaside_buffer

These are typical performance levels of a TLB:

size: 12 bits – 4,096 entries

hit time: 0.5 – 1 clock cycle

miss penalty: 10 – 100 clock cycles

miss rate: 0.01 – 1% (20–40% for sparse/graph applications)

If a TLB hit takes 1 clock cycle, a miss takes 30 clock cycles, and the miss rate is 1%, the effective memory cycle rate is an average of 1 × 0.99 + (1 + 30) × 0.01 = 1.30 (1.30 clock cycles per memory access).

Yes, but users rarely see real amount of virtual memory used (reserved, committed, etc). For example Chrome rendering process right now on my machine uses 267 MB of physical memory, 478 MB of committed virtual memory, and 2.1 GB of virtual address space.

So as you can imagine, total address space reserved on a machine can easily go into terabyte range. But that doesn't matter because every process get it's own lookup table.

Poul-Henning Kamp is rather famous for writing code that uses mmap and a straightforward data structure for giant blobs of data and arguing that the kernel memory manager should handle the details. To my knowledge, most people dealing with data larger than memory use more active techniques.

If portability is a goal, the mmap approach will require a higher investment with more documentation on system tuning to recognize the benefit. But if you're deploying to one architecture with strong support for mmap, go for it.

"One architecture". Like Linux on x86-64? That's the only one that matters for 99% of us.

You have no idea how much money businesses have lost in the long run, because they said that about IBM mainframes.

Keep your options open by keeping your code portable.

A common failure mode for this is that devs and less sophisticated Ops people see that the machine is only “using” 60% if available memory and they carve out a chunk for another process or a feature. They don’t get that file caching and mmapping are providing them a lot of their performance, and aren’t clearly accounted for by ‘free’.

So suddenly we are at 90% memory and everything is slow as molasses.

Or say things like, "had 90% of their CPU available for twiddling their digital thumbs". CPU usage is irrelevant if all your processes are blocked on i/o.

This could mean 'address space reserved but not committed'. Committed address space is often much smaller than reserved address space - think of how the stack starts out with very little actual memory in use, and then grows as unused pages are first touched. That mechanism ensures that spinning up a temporary thread with a shallow stack doesn't eat up 8mb of physical memory instantly.

The pages are also zeroed on-demand when committed, which ensures thread creation doesn't first require 8mb of pages to be zeroed (There are workarounds for that as well).

> Ok, question from someone clueless without recent low-level programming experience - is this in fact a normal situation on modern systems?

Great question. Where I work, it's common to have swap disabled (or only use zram-backed swap, so pages may be stored compressed in RAM but never actually get sent to SSD much less spinning disk) and mlock the executables into RAM. So in my experience it's uncommon for memory accesses to wait for secondary storage (because we've decided to avoid it).

On the other hand, I think the author's definition is poor:

> "VM pressure, measured in the amount of address space not resident in primary memory"

By this definition, the systems I just described have lots of VM pressure. Thread stacks contribute: there might be 64 kiB on up to 4 MiB of address space reserved for a thread's stack (plus a 4 KiB guard page) but none of that is actually backed by real physical RAM until it's first accessed. So often the thread stacks will only occupy 4 KiB of actual RAM (one page).

I'd say however a more useful definition of memory pressure is based on time spent waiting for something to be paged in. See also the recent Linux "pressure stall information" work. By this definition, those non-backed-pages don't contribute to memory pressure much. (Minor page faults, which find a page of physical RAM to match the virtual page and write zeroes to it, are typically fast unless physical RAM is actually hard to find or (at least on Linux) there's heavy contention on the process's mmap_sem.)

> Because I had the general impression that ... that virtual memory is more of a historical appendix than anything.

Virtual memory is still useful for lots of things besides using SSD or disk to extend RAM: allocating address space before backing RAM (as I just described for thread stacks; also iirc ASAN/TSAN take advantage of this), zram-backed swap, and memory-mapped file I/O come to mind.

I think what the author says here is not terribly common:

> A 300GB backing store, memory mapped on a machine with 16GB or less RAM is quite typical. The user paid for 64bit of address-space, and I am not afraid to use it.

It's common for the author's application because he's designed it that way. He doesn't supply any data to make us think it's common in other applications so his advice may not be generally applicable. And he's also not using what I'd consider to be a correct definition of memory pressure. So plenty of reasons to suspect true memory pressure is an "extreme corner case" for most people (in applications other than Varnish), despite his saying "this is pretty much the real-world behavior seen."

I'm unsure from a quick skim if the B-heap he's describing is large and resides in the memory-mapped on-disk pages or if it's small and resides in anonymous pages. If the latter, it may be better to simply mlock() it in RAM so it you can guarantee there are no page faults while it's accessed.

I'd hate to have this discussion with the author because he sounds insufferably arrogant. Another commenter pointed out that this "paper" (I'd say rant) didn't go over well with the ACM crowd, and no wonder why...

Reply on news.ycombinator.com