I think the more fundamental issue is that transparent huge pages can break the assumed (key word) interface between the application and the system, and this ca

I think the more fundamental issue is that transparent huge pages can break the assumed (key word) interface between the application and the system, and this can manifest in very non-obvious ways. Only the application knows the workload characteristics for using the pages it has reserved, and THP messes with assumptions you might be making otherwise. This turns it into a pessimization, overall. For example, if I map a bunch of pages of memory, use some, and then set MADV_DONTNEED on just a few of those pages afterwords (so they can be given back to the system temporarily), this will only work if I know the entire page is unused. If a page magically gets 512x larger under my feet, it's possible it will "coalesce" with another page -- into a huge page -- that can't be given back, because some of the (now much larger) page is still needed. This is the case of what happens with `jemalloc` + `redis`, where what looks like a memory leak is actually a failure to give back pages to the operating system, because small pages coalesce into huge ones automatically, defeating MADV_DONTNEED. Whether or not malloc(2) uses THP "under the hood" in this case is more an implementation decision (there are many malloc variants), but it just punts the problem down the road. Ultimately it manifests as a violation of the "unspoken protocol" between the kernel and application when managing memory mappings. All that said, there's some posts elsewhere in this thread pointing out that FreeBSD's Huge Page implementation avoids some of these deficiencies (possibly as a trade for some of its own), so all that said -- there's still room for better implementations, clearly: https://www.cs.rice.edu/~druschel/publications/superpages.pdf https://www.cs.rice.edu/~druschel/publications/superpages.pd...