Explore Huge Pages: Benchmark 4KB vs 2MB Pages

Bigger TLB Reach

Huge pages (commonly 2 MB on x86) reduce TLB misses for large contiguous mappings. Each TLB entry covers more virtual range, so scanning a 1 GB array touches fewer translation lookups.

4 KB vs 2 MB Tradeoff

Comparison points:

• TLB pressure: 4 KB needs 512 entries per GB; 2 MB needs 1
• Fragmentation: huge pages require aligned contiguous physical memory
• Setup: mmap with MAP_HUGETLB or madvise(MADV_HUGEPAGE)

For example, a random walk across a 2 GB buffer may show 40% fewer dTLB misses with transparent huge pages enabled.

Why This Matters in Production

Databases like PostgreSQL and Oracle explicitly enable Linux huge pages (hugetlbfs or Transparent Huge Pages) to cut TLB misses when scanning gigabytes of buffer cache during large sequential scans. Get the trade-off backwards , using 2MB pages for small, sparse allocations , and you waste RAM through internal fragmentation instead of saving CPU cycles.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will benchmark identical workloads with normal and huge pages, reading /proc/self/smaps or perf counters. The task asks you to explain when huge pages hurt due to internal fragmentation.