Turn on UseNUMA by default when prudent

[Eric Caspole]

On May 29, 2012, at 4:09 PM, Vladimir Kozlov wrote:

> Jesper Wilhelmsson wrote:
>> Hi Eric,
>> As long as this is based on actual data and not just a hunch, I  
>> personally think it is a good idea. I don't know if we have any  
>> policies about platform specific optimizations like this though.
>> I have some comments on the code layout and there are a few typos,  
>> but I guess this is still a draft so I won't pick on that right now.
>> One thing I wonder though is in os_linux_x86.cpp:
>> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family()  
>> == 0x10) {
>
> Yes, this code should be in vm_version_x86.cpp file. I also would  
> like to see this more general for all OSes.

Any volunteers to help get this working for Solaris/SPARC? You use  
this flag, right?
Then it will be easier to see where to place is_numa_machine() type  
methods etc.


>
> Thanks,
> Vladimir
>
>> Is this the only way to identify the proper processor family? It  
>> doesn't seem very future proof. How often would you have to change  
>> this code to keep it up to date with new hardware?
>> Regards,
>> /Jesper
>> On 2012-05-29 20:54, Eric Caspole wrote:
>>> Hi Hotspot team,
>>>
>>> We sometimes notice on multi-socket systems large run to run  
>>> variation in some
>>> benchmarks which seems to be attributed to bad/unlucky numa  
>>> behavior. So we
>>> would like to add simple checks to turn on +UseNUMA for AMD  
>>> platforms in the
>>> right situations; for example, max heap >= 4GB and we detect a  
>>> multi-socket
>>> system. This should be a useful out-of-box improvement for most  
>>> customers
>>> since UseParallelGC is the default.
>>>
>>> For benchmarks with a large heap, it helps give better out-of-box  
>>> performance
>>> in many cases.
>>>
>>> Here is my first webrev to turn on NUMA for AMD systems when it  
>>> is a numa
>>> system and the heap is set >= 4GB.
>>>
>>> http://cr.openjdk.java.net/~ecaspole/numa_default/
>>>
>>> Please let me know your thoughts on the merit of doing this and  
>>> if it is
>>> worthwhile what should be the structure of the change in the  
>>> shared/os/cpu
>>> specific code.
>>>
>>> Thanks,
>>> Eric
>>>
>>>
>