RFR: 8205051: Poor Performance with UseNUMA when cpu and memory nodes are misaligned [v5]

[Derek White]

On Mon, 16 Dec 2024 11:45:14 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
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8205051: Minor comment change

Hi Alan, I think the general practice is if the command line asked for something (UseAVX=3, -Xdebug, etc), and the JVM can't do it, then print some kind of warning. 

The UseNUMA code didn't print a warning previously if UseNUMA was disabled by the JVM, but curiously _did_ print a warning if the JVM disabled UseAdaptiveSizePolicy, due to UseNUMA and UseLargePages being enabled. I think the new code is an improvement, but we're happy to update if there's consensus.

Additionally @jaikiran asked in [JDK-8346834](https://bugs.openjdk.org/browse/JDK-8346834) about the specific format of the warning - old warning or unified logging warning, which is probably a bigger question.

Sorry for the unexpected failures!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22395#issuecomment-2568271919