Integrated: 8205051: Poor Performance with UseNUMA when cpu and memory nodes are misaligned
Swati Sharma
duke at openjdk.org
Mon Dec 23 19:18:42 UTC 2024
On Tue, 26 Nov 2024 17:25:03 GMT, Swati Sharma <duke at openjdk.org> wrote:
> Hi All,
>
> The PR handles the performance issues related to flag UseNUMA. We disable the UseNUMA flag when the process gets invoked with incorrect node alignment.
> We check the cpunodebind and membind(or interleave for interleave policy) bitmask equality and disable UseNUMA when they are not equal.
> For example on a 4 NUMA node system:
> 0123 Node Number
> 1100 cpunodebind bitmask
> 1111 membind bitmask
> Disable UseNUMA as CPU and memory bitmask are not equal.
>
> 0123 Node Number
> 1100 cpunodebind bitmask
> 1100 membind bitmask
> Enable UseNUMA as CPU and memory bitmask are equal.
>
> This covers all the cases with all policies and tested this with below command
> numactl --cpunodebind=0,1 --localalloc java -Xlog:gc*=info -XX:+UseParallelGC -XX:+UseNUMA -version
>
> For localalloc and preferred policies the membind bitmask returns true for all nodes, hence if cpunodebind is not bound to all nodes then the UseNUMA will be disabled.
>
> This PR covers disabling the UseNUMA flag for all GC's hence we observed an improvement of ~25% on G1GC , ~20% on ZGC and ~7-8% on PGC in both throughput and latency on SPECjbb2015 on a 2 NUMA node SRF-SP system with 6Group configuration.
>
> Please review and provide your valuable comments.
>
> Thanks,
> Swati Sharma
> Intel
This pull request has now been integrated.
Changeset: 62a4544b
Author: Swati Sharma <swati.sharma at intel.com>
Committer: Derek White <drwhite at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/62a4544bb76aa339a8129f81d2527405a1b1e7e3
Stats: 61 lines in 2 files changed: 48 ins; 3 del; 10 mod
8205051: Poor Performance with UseNUMA when cpu and memory nodes are misaligned
Co-authored-by: Derek White <drwhite at openjdk.org>
Reviewed-by: sjohanss, tschatzl
-------------
PR: https://git.openjdk.org/jdk/pull/22395
More information about the hotspot-runtime-dev
mailing list