LWN: Comments on "Transparent huge pages in 2.6.38"

Transparent huge pages in 2.6.38

pfefferz — 2011-03-20T20:29:10+00:00

Hugepages are a big deal for Mobile SoCs. Designers preallocate large chunks of physical memory to ensure that their encode/decode blocks operate on contiguous memory. This large memory gets locked out of the system forever. This leads to increased system costs because manufactures need to put down more memory than they'd like to.

Some SoC manufactures have started using IOMMUs to map memory, but they're running up against TLB depth which they solve by using hugepages instead of regular pages. This support should allow these IOMMUs to map memory at runtime with hugepages and theoretically allow manufactures to use less memory. Of course that won't happen since hugepages are very scarce.

I wrote an IOMMU prototype that used its own allocator and presented it at OLS in 2010, The Virtual Contiguous Memory Manager. I think the Samsung guys put together something based on its ideas.

Hugetlbfs pages are dynamically allocate-able

emunson — 2011-01-21T15:35:14+00:00

The presence of contiguous memory will be entirely dependant on the system and work load. You are correct that allocating huge pages becomes more difficult as memory is fragmented. My reply was to the section of the article that said hugetlbfs based huge pages must be set aside at boot time which is not correct for all page sizes. On systems that support them, 1GB and 16GB pages must be reserved at boot, but 2MB, 4MB, and 16MB pages can be allocated any time there is contiguous space.

Hugetlbfs pages are dynamically allocate-able

jthill — 2011-01-21T09:31:08+00:00

I think the memory compaction patch is intended to fix that:

Mel ran some simple tests showing that, with compaction enabled, he was able to allocate over 90% of the system's memory as huge pages while simultaneously decreasing the amount of reclaim activity needed.

Hugetlbfs pages are dynamically allocate-able

Tuna-Fish — 2011-01-21T06:38:36+00:00

Only if there is contiguous real memory available. Under real-world situations, there rarely is.

Just try allocating space on hugetlbfs after running an active web server for a few hours.

Hugetlbfs pages are dynamically allocate-able

emunson — 2011-01-20T17:12:28+00:00

Your description of using huge pages via hugetlbfs is not quite correct. Most modern kernels and architectures support dynamically allocating huge pages after boot.

Transparent huge pages in 2.6.38

Tuna-Fish — 2011-01-20T15:36:03+00:00

Transparent hugepage support is very interesting at the moment -- especially because both main x86 vendors are beefing up the support for them in their processors. Intel just added real support for 1GiB pages, but AMD takes the jackpot with the DTLB in the upcoming Bulldozer -- 72 L1 entries and 1024 L2 entries, holding any combination of 4kiB, 2MiB or 1GiB pages.

Transparent huge pages in 2.6.38

rfrancoise — 2011-01-20T12:27:35+00:00

Andrea gave a talk on THP at the KVM Forum 2010 with some interesting benchmark results: slides, video.

Transparent huge pages in 2.6.38

jreiser — 2011-01-20T06:40:31+00:00

Huge pages can increase data cache performance by making aliasing (the mapping of address to cache set) more uniform within the huge page, in contrast to the mappings for many equivalent collections of small pages. The difference can be several percent or more.