Change to numactl

[diegolovison]

taskset limitations:

• Only pins CPU cores
• No memory placement control
• Risk of cross-NUMA memory access penalties (2-3x slower)

numactl advantages:

• Memory locality: --membind=0 ensures memory stays on same NUMA node as CPUs
• Complete NUMA awareness: Coordinates CPU and memory placement together
• Consistent performance: Eliminates NUMA-related variance between benchmark runs
• Reproducible results: Prevents OS from migrating memory across NUMA boundaries

Changed from taskset --cpu-list to numactl --membind=0 --physcpubind= ensures both CPU affinity and memory locality, which is critical for accurate performance comparisons between Quarkus and Spring Boot applications. This eliminates a major source of measurement noise in multi-socket systems.

Found because of:

load-test-quarkus3-jvm-0.log

[0.020s][warning][os] NUMA support disabled: The process memory and cpu node configuration does not match
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   

load-test-spring4-jvm-0.log

[0.020s][warning][os] NUMA support disabled: The process memory and cpu node configuration does not match

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::                (v4.0.5)

---

We also removed -XX:+UseNUMA from the wrk JVM args, which makes sense since numactl now handles NUMA policy at the process level, making the JVM flag redundant.

Found because

Warning: The process is bound to a single NUMA node

[diegolovison]

@edeandrea wait for @franz1981 feedback.

[franz1981]

The warning is because taskset properly set the application execution to cores on the same numa node, which means that numactl is not responsible to have fixed the warning.

I would avoid using numactl as some users could run on bare metal instances with single numa node and taskset would be available to them, whilst numactl, nope.

For the memory allocation, the OS policy is "local-first", making the isolation issue less of an issue, in many cases.

If we decide that numactl become an hard constraints and hard requirement for our script, we should make sure that Google cloud/AWS/IBM bare metal instances can use it, if single numa node.

[diegolovison]

taskset vs numactl
taskset is installed by default, and numactl is not. The benchmark requires other packages like jq that are not installed by default as well. In this case, we can install numactl as well

Memory Policy ("local-first")
Yes. numactl --membind can be considered redundant here? We can say yes, but it will force the PID to not go outside that NUMA node. If the benchmark is very memory-intensive, without it, we start dealing with the unknown. By moving data to another node, we start having a few ns.

The warning
The warning "NUMA support disabled" is a trick. It makes you believe that it numa is not working. IMHO, better to not have it.