Huge pages are a good idea (opens in new tab)

I think most applications don't have any dependency towards a specific page size. They use malloc (C) or new (C++) to allocate memory which does not expose this constraint.

You need to care if using mmap directly to map files or other resources into the virtual memory address space. The default page size can be queried using for example sysconf() on Linux. I guess something like garbage collectors in language run-times would also use mmap directly as it's most likely to side step malloc/new.

An application would normally not use madvise, unless also using mmap for some special purpose.

It depends on the CPU architecture how flexible it is with different page sizes. For example, from what I recall, MIPS was extremely flexible and allowed any even power of two size for any TLB entry.

x86_64 only support three different page sizes, 4 kB, 2 MB and 1 GB and there are limitations wrt the number of TLB entries that can be used for the larger page sizes.

So, yea, there are bound to be regressions if just trying to switch to 2 MB as a default but I think it should be doable. Not all archs use 4 kB to begin with.

You can call sysconf(_SC_PAGESIZE) to get page size. Problem with transparent huge pages is that you get regular page size (4k) from sysconf(), but then OS sometimes use 2M instead.

Just switching to larger regular page size (e.g. 64k) on platforms that support it would not have problems associated with THP.

The article has some examples of breakage, and these are mostly using an allocator other than the system allocator which hard codes a 4k page size (Go, Chrome, jemalloc) at least for x86 and arm.

Why did they assume that? 4k pages are a feature of the memory management unit of the cpu. Optional support for large pages came to x86 with pentium in the mid-1990’s. Presumably all x86 cpus out there today have large page support, but the assumption of the 4k default is deeply ingrained.

> Huge pages are an absolutely great idea. I will continue to complain about our eternal commitment to 4k pages, with all their pitfalls, which it appears we may be stuck with until the heat death of the universe.

I think it is useful to distinguish just larger regular pages (i.e. 16k or 64k pages on arm64) and extraordinary huge pages (2M on systems where regular pages are 4k). In the first case, the system uses these larger pages uniformly, as there is no smaller page.

Huge pages are not a great idea, increasing the page size from 4k is.

The part in the article about ARM64 Linux giving up on 64kb pages was particularly damning. Although as it notes, Apple is using something other than 4gb pages at least.

macOS on Apple Silicon and iOS use 16kiB pages without lying to applications.

Linux has a MAP_HUGETLB constant, which you can pass to mmap(), which opts your application into 2MiB or 1GiB pages. Unfortunately, last time I tried it it required the system admin to enable support in the system for that, which wasn't on by default (on Debian at least). So from the perspective of an ordinary application developer that's useless.

Memory sizes have increased, but so have the workloads that people run. It's not like our computers still only consume a few MBs of RAM and we have 1000x times more free memory than we used to.

Going from 4k to 2M doesn't waste a fixed amount of memory, it wastes a percentage of memory. So the amount of memory lost continues to scale with memory size. Losing 10% of your memory when you only have 32MB hurts just as much as losing 10% when you have 32GB, because we didn't have a 1000x times increase in free RAM. Applications just use more RAM than they used to.

Now an increase to 8k, 16k, or even 64k might be defensible. And even that last one will draw some scowls from very serious people. But going straight to 2M pages by default will not be a good tradeoff. Especially since the current system with differently sized pages gets you most of the performance gain for a much more reasonable cost.

Note that more memory does not necessary mean that everything is uniformly bigger, as there is some strongly-non-uniform distribution of memory map sizes, and more memory most likely means that large maps goes larger.

Take for example bash: its RSS is about ~4 MB, but it has 43 memory maps (on my system). One is > 1MB, two are 512-1024 kB, most are very small. Each requires at least one page, so with mandatory 2 MB pages, its RSS would be 86 MB instead of 4 MB.

Were there no downside it would be a default. Perhaps ask "isn't it a no-brainer to use large pages" rather than declare it is without saying why you think so.

Edit: I did a quick search. upside of less TLB thrashing, downside of potentially more disk thrashing as pages are paged in and out.

Indeed. Something significant is lost when the "Huge" is omitted. Memory pages being good idea is essentially a tautology at this point, but the use of huge (much larger than 4k) memory pages being a universally good idea is much less obvious and more nuanced, and ultimately, potentially even untrue.

Sorry, I didn't mean to trim that.

> I remember when hard drives moved to 4k sectors. It seemed insane that they were still 512bytes, and seemed neat to have them the same size as memory pages. But 4k pages seem incredibly small today

It's a problem with NVMe especially large ones: we're just starting to see 4kn.

Even for a 4kn drive, the block size they report (and the erase block size) are not the ones used internally. There are some tools to infer the correct size using breakpoint detection in latency measurements.

There're also some simple rule of thumb: 2^16 for Samsung >1Tb (64k)

Huge pages need contiguous free physical pages. Without preallocating them at boot time, with higher system uptime, chances of finding such region to satisfy the allocation are slimmer, especially for 1G pages, to the point when even services starting later at boot time might not get them due to external fragmentation caused by 4k pages allocations.

While I can see why special permissions are needed to grab them, the whole filesystem thingy is clunky as hell. I have no idea why they didn't put them by default in /sys or /proc.

> This should all just be a single boolean flag in the database config telling it to use huge pages which it gets from mmap dynamically. Why is any of the filesystem, permission, static allocation malarkey necessary?

FWIW, those bits shouldn't be necessary with postgres. If huge_pages is try or on, we'll specify MAP_HUGETLB (or (shift & MAP_HUGE_MASK) << MAP_HUGE_SHIFT if huge_page_size is set). If mmap() fails we'll error (=on) out or fall back to non-huge allocation (=try)

However, you do need to allocate huge pages on the system level for this to succeed. But it's indeed just a /proc (or /sys if you want more control). /proc/sys/vm/nr_hugepages, or /sys/kernel/mm/hugepages/hugepages-kB/nr_hugepages.

One of the more awkward bits about the kernel config is that they are calculated in pages, so you need to do the conversion yourself :(

   echo $(( (32 * 1024*1024*1024) / (2 * 1024 * 1024) + 1)) | tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages && cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Update: I believe I was fooling myself. I was running the new code, then the old code, and the new code was consistently beating the old code. But, when I reversed the order, and ran the old code first, then the new code, the old code beat the new code! Then I started monitoring CPU temperatures during the tests. Turns out the code to run first was starting with cooler CPUs and getting a little head start on the work with a longer time before thermal throttling kicked in. If I wait for things to cool down between runs, then the old code (no huge pages) consistently beats the new code (huge pages) but only by a very small amount. Benchmarking is hard.

Things have changed since then, now you can do per application malloc backed huge pages.

The `madvise` setting of THP was never problematic for anyone. The Redis people made a huge stink about it because 1) they don't know what they are talking about and 2) the architecture of their program is really bizarre. Consequently it is now a widespread myth that you must set THP to `never` or else it is hazardous. But being widespread does not make it any less of a myth.