RFC: Proposal: Add NUMA Memory Policy Tunable to glibc malloc implementation

[罗春生]

Hello dear community,

I'm writing to propose a new feature for integrating NUMA memory policy control directly into glibc's memory allocator, which would address significant challenges in early-stage memory allocation control on NUMA systems.

Problem Context:
Current approaches for setting NUMA policies (interleave, bind, preferred) at program startup face limitations:
1. Applications requiring memory policy control before main() have no  reliable mechanism
2. Using malloc hooks (LD_PRELOAD) for early NUMA policy setting is problematic due to recursive malloc calls in libnuma functions


Related discussion in numactl project:
https://github.com/numactl/numactl/issues/248
https://github.com/numactl/numactl/pull/249

Proposal:
Introduce a new glibc tunable parameter: `glibc.malloc.mempolicy`
- Values:
  - 0: Default (no policy)
  - 1: MPOL_BIND
  - 2: MPOL_PREFERRED
  - 3: MPOL_INTERLEAVE
  - 4: MPOL_LOCAL

Implementation would:
1. Apply during ptmalloc initialization (before any user allocations)
2. Call set_mempolicy() system calls internally
3. Use node mask from existing GLIBC_TUNABLES (e.g., glibc.malloc.arena_nodes)

Technical Advantages:
1. Eliminates recursion risks from LD_PRELOAD hooks
2. Provides standard mechanism across all glibc-supported architectures
4. No external library dependencies (avoids libnuma constraints)

*Backward Compatibility:
- Would default to current behavior (no policy) when unset
- Could coexist with libnuma for runtime policy changes

Patch Status:
I have an experimental implementation locally but believe community guidance is essential before formal submission. This approach appears preferable to maintaining potentially hazardous malloc hook solutions that:
- Introduce recursion risks
- Create maintenance burdens
- Cause unexpected performance cliffs

Would the glibc community be open to such an extension? I'd welcome guidance on:
1. Appropriate tunable naming convention
2. Preferred implementation approach
3. Testing expectations
4. Cohesion with existing NUMA-aware features

Thank you for considering this proposal. I look forward to community feedback and would be happy to develop a formal patch following your guidance.

Best regards,
Chunsheng Luo





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250804/6139f577/attachment.htm>