Skip to content

Add huge page support for symmetric heap to improve CXI ATU performance - #1234

Draft
bcmIntc wants to merge 7 commits into
Sandia-OpenSHMEM:mainfrom
bcmIntc:huge-page-support-clean
Draft

Add huge page support for symmetric heap to improve CXI ATU performance#1234
bcmIntc wants to merge 7 commits into
Sandia-OpenSHMEM:mainfrom
bcmIntc:huge-page-support-clean

Conversation

@bcmIntc

@bcmIntc bcmIntc commented Jun 5, 2026

Copy link
Copy Markdown
Collaborator

This PR adds support for 2MB huge pages in the symmetric heap allocation, enabling the CXI NIC's Address Translation Unit (ATU) to use more efficient 2MB page translations instead of 4KB base pages. This significantly improves ATU cache hit rates on systems with CXI interconnects.

Changes

Symmetric heap: Anonymous MAP_HUGETLB allocation

When SHMEM_SYMMETRIC_HEAP_USE_HUGE_PAGES=1 is set, the symmetric heap now uses anonymous MAP_HUGETLB with explicit 2MB page size:

  • Uses MAP_HUGETLB | (21 << MAP_HUGE_SHIFT) to request 2MB pages explicitly
  • Leverages kernel's nr_overcommit_hugepages mechanism for on-demand surplus huge page allocation
  • No pre-reserved huge pages (HugePages_Total) required
  • Graceful fallback chain ensures compatibility:
    1. Hugetlbfs file mapping (if mount available)
    2. Anonymous MAP_HUGETLB (primary mechanism)
    3. Transparent huge pages via madvise(MADV_HUGEPAGE)
    4. Regular 4KB pages (last resort)

Implementation details

  • Modified mmap_alloc() in src/symmetric_heap_c.c
  • Changed hugetlbfs file open failure from warning to debug message (fallback works correctly)
  • Uses requested_base as address hint to keep heap in expected memory region

Performance Impact

Testing on Perlmutter (NERSC) with --enable-ofi-mr=scalable configuration:

Metric Value
ATU 2MB page hits (derivative1) 80-82% (~44-49M hits)
ATU 4KB page hits (base) 18-20% (~10-11M hits)
Surplus huge pages allocated ~33,024 pages (~66GB)

Without huge pages, the ATU would predominantly use 4KB translations, resulting in higher cache miss rates and increased address translation overhead during RDMA operations.

Configuration

Build-time

--enable-ofi-mr=scalable  # Required: registers entire address space,
                          # allowing CXI provider to detect page sizes

Run-time

export SHMEM_SYMMETRIC_HEAP_USE_HUGE_PAGES=1

System requirements

  • Linux kernel 3.8+ (for MAP_HUGE_SHIFT support)
  • vm.nr_overcommit_hugepages > 0 (check with cat /proc/sys/vm/nr_overcommit_hugepages)
    • Already configured on Perlmutter and similar HPC systems
    • Can be set via: sudo sysctl -w vm.nr_overcommit_hugepages=<N>

Compatibility

  • Fully backward compatible: defaults to existing behavior when SHMEM_SYMMETRIC_HEAP_USE_HUGE_PAGES is not set or 0
  • Graceful degradation: automatically falls back to smaller page sizes if huge pages unavailable
  • Platform support: Linux only (uses #ifdef __linux__ guards)
  • No impact on non-CXI systems: huge pages improve performance broadly, but ATU benefits are CXI-specific

Testing

Validated on:

  • Perlmutter (NERSC) - CXI interconnect, scalable MR mode
  • Telemetry confirms 80%+ of ATU translations using 2MB pages
  • Benchmark performance maintained with improved ATU efficiency

Commits

  1. b08a5e3f - symmetric heap: use anonymous MAP_HUGETLB for huge page allocation
  2. c3770a50 - Formatting
  3. 8f0d93d4 - symmetric heap: change hugetlbfs file warning to debug message

bcmIntc and others added 3 commits June 5, 2026 12:09
When SYMMETRIC_HEAP_USE_HUGE_PAGES is enabled but no hugetlbfs mount is
configured, use anonymous MAP_HUGETLB with explicit 2MB page size instead
of falling back to transparent huge pages (THP).

This allows the kernel's nr_overcommit_hugepages mechanism to dynamically
allocate surplus huge pages on demand without requiring pre-reserved
HugePages_Total. Anonymous MAP_HUGETLB with (21 << MAP_HUGE_SHIFT)
explicitly requests 2MB pages, matching the CXI provider's behavior.

When used with scalable MR mode (--enable-ofi-mr=scalable), this enables
the CXI NIC's ATU to use 2MB page translations (derivative1) instead of
4KB base pages, significantly improving ATU cache hit rates.

Fallback to THP via madvise(MADV_HUGEPAGE) still occurs if MAP_HUGETLB
fails, ensuring compatibility across different kernel configurations.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Change the hugetlbfs file open failure from RAISE_WARN_STR to DEBUG_MSG
since the fallback to anonymous MAP_HUGETLB works correctly. The warning
was misleading because huge pages were still being allocated successfully
via the anonymous MAP_HUGETLB path.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@bcmIntc bcmIntc self-assigned this Jun 5, 2026
@bcmIntc bcmIntc changed the title Huge page support clean Symmetric heap: Anonymous MAP_HUGETLB allocation Jun 5, 2026
@bcmIntc bcmIntc changed the title Symmetric heap: Anonymous MAP_HUGETLB allocation Add huge page support for symmetric heap to improve CXI ATU performance Jun 5, 2026
Comment thread src/symmetric_heap_c.c Outdated
/* Try anonymous MAP_HUGETLB first (works with nr_overcommit_hugepages).
* Explicitly request 2MB pages via MAP_HUGE_SHIFT (21 << MAP_HUGE_SHIFT = 2^21 = 2MB). */
ret = mmap(requested_base, bytes, PROT_READ | PROT_WRITE,
MAP_ANON | MAP_PRIVATE | MAP_HUGETLB | (21 << MAP_HUGE_SHIFT), -1, 0);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to check the environmental variable SHMEM_SYMMETRIC_HEAP_PAGE_SIZE to see if it is set to 2MB before setting the 2MB page flag.

The default for SHMEM_SYMMETRIC_HEAP_PAGE_SIZE is set to 2MB so the additional check will not change the behavior.

bcmIntc and others added 4 commits June 9, 2026 07:22
…ndling

- Fix double free: set directory/file_name to NULL after freeing
- Fix size bug: preserve original bytes, only use hugetlbfs_bytes for file path
- Fix fallback: use NULL address hint after MAP_HUGETLB failure
- Add debug visibility: log which allocation path succeeded
- Change hugetlbfs warnings to debug messages (fallback works correctly)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…in fallbacks

- Fix Issue 1 (munmap size mismatch): add size_t *mapped_bytes out-parameter
  to mmap_alloc(). On the hugetlbfs success path the mapping is rounded up to
  a huge-page boundary (hugetlbfs_bytes > bytes); the previous code passed the
  original unrounded size to munmap and transport registration (OFI, Portals4,
  UCX, XPMEM), leaking the tail pages from the huge-page pool. mmap_alloc now
  reports the actual mapped size, and shmem_internal_symmetric_init updates
  shmem_internal_heap_length accordingly so munmap, registration, and bounds
  checks all use the correct extent.

- Fix Issue 2 (requested_base dropped on fallback): both THP fallback paths
  (ftruncate failure and MAP_HUGETLB failure) previously used mmap(NULL, ...)
  unconditionally. This discards the requested_base hint (data segment + 2 GB,
  1 GB-aligned) that is required for --enable-remote-virtual-addressing to
  maintain symmetric virtual addresses across PEs. The fallbacks now first
  attempt mmap(requested_base, ...) and only resort to mmap(NULL, ...) if
  that also fails. Remove the incorrect comment claiming requested_base will
  not work after MAP_HUGETLB failure.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Use put_quiet instead of unreliable completion watermark. The watermark
approach fails because put_nb uses different code paths (inject, bounce
buffer, put_large) that don't all update the completion counter reliably.

put_quiet guarantees all in-flight puts complete regardless of path taken.

Co-authored-by: GitHub Copilot <copilot@github.com>
Update comment to better explain why put_quiet is necessary. The inject
path has no counter event, so put_wait with completion=0 would return
immediately and leave GPU writes unordered, causing a data race.

put_quiet provides the NIC-level ordering fence needed for correctness.

Co-authored-by: GitHub Copilot <copilot@github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants