3 ms·
The OS presents a view of a flat memory space to userspace processes, but it's not real. Memory is really segmented into 4 KB pages. Every time an application
by hapless 15y ago
The OS presents a view of a flat memory space to userspace processes, but it's not real. Memory is really segmented into 4 KB pages. Every time an application accesses its flat memory space, there are layers of indirection to trace before winding down to the real, physical page.
The system has a cache to store the indirection results, so that memory within a cached page can be accessed quickly, without tracing the indirections. Unfortunately, on x86 systems, this cache of indirection results (the TLB) is very, very very small. One way to stretch the TLB is to allow the indvidual TLB entries to handle more data by increasing the page size.
With transparent hugepages, if an application requests 32 MB of RAM, the system can allocate a single "hugepage" of 32 MB. That "hugepage" occupies a single entry in the TLB, instead of thousands of 4 KB pages. Fewer entries eaten means fewer indirections traced when multiple processes are competing for resources.
In other words, memory access under contention is faster and context switches are less expensive when you have transparent hugepages enabled. That's a big performance win for virtualization hosts, because they are likely to experience a lot of contention.