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

[Adhemerval Zanella Netto]

On 05/08/25 03:42, 罗春生 wrote:
> To Florian:
> 
> >> The original proposal addressed a specific timing challenge: critical
> >> allocations occurring during the initialization sequence: ld.so
> >> initialization → early malloc calls → first user call to
> >> set_mempolicy()
> 
> > If the parent process calls set_mempolicy, the policy gets applied to
> > these earlier allocations, too.  
> 
> If the parent process calls set_mempolicy, the parent process will also go
> through `ld.so initialization → early malloc calls → main() -> 
> first call to set_mempolicy`, and these earlier allocations still will exist.
> 
> Now numactl takes advantage of the process inheritance property of mempolicy. 
> It first sets the memory policy and then executes the target application through execv. 
> usage : numactl [mempolicy] command args .... , In this way, early malloc behavior 
> will also exist when numactl is executed. 
>

I think you and Florian are talking about different approaches.  Afaiu
Florian is saying that running the program through numactl should be
suffice to provide any NUMA tuning necessary to the process.

What you are proposing is for the case where the process is not started
with a wrapper, but rather setup through a library (like libnuma) or by
LD_PRELOAD.

I think adding such support on glibc would require adding a lot of
more functionality, since set_mempolicy now supports some flags and,
and depending of the argument, a configurable node flag.  

In theory you can make it with something similar to what glibc does,
where you add a new environment variable (LIBNUMA_MEMPOLICY or
something like), parse it, and apply the memory polity prior any
other setup in libnuma. It does not help on library with multiple
constructors, since the order may vary.

So I think the real question here is why can't you implement this
on libnuma?