United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7060836 RHEL 5.5 and 5.6 should support UseNUMA
JDK-7060836 : RHEL 5.5 and 5.6 should support UseNUMA

Details
Type:
Bug
Submit Date:
2011-06-29
Status:
Closed
Updated Date:
2011-11-25
Project Name:
JDK
Resolved Date:
2011-09-30
Component:
hotspot
OS:
linux_redhat_5.0
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs22 (b02)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
RHEL 5.5 and 5.6 don't support UseNUMA because the locality group id implementation
is done via a call to sched_getcpu(), which was introduced in only in recent versions
of libc. In the case of RHEL 5.5 and 5.6, Hotspot cannot find sched_getcpu and UseNUMA
is disabled.

                                    

Comments
SUGGESTED FIX

A patch which enables UseNUMA for older systems (sched_getcpu_syscall.patch)
is attached, and/or see

 http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=ddbf2447886c
                                     
2011-06-29
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7c2653aefc46
                                     
2011-08-06
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c2653aefc46
                                     
2011-08-17
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7c2653aefc46
                                     
2011-08-17
PUBLIC COMMENTS

> On 8/7/11 5:22 PM, David Holmes wrote:
>>
>> I seemed to have missed the discussion of this CR and the suggested fix. I 
>> have a concern that this may cause compilation failures on some older 
>> Linux systems because SYS_getcpu and/or __NR_vgetcpu will not exist. I 
>> started trying to use sched_getcpu a few years back for the RTSJ 1.1 
>> processor affinity API support that I started to prototype. 
>> There were a number of issues on our main RT linux systems
>> because of the different statuses of the libc function and the 
>> syscall. The code that I was intending to use was as follows:
>>
>> 32-bit:
>>
>> #ifndef SYS_getcpu
>> #define SYS_getcpu 318
>> #endif
>>
>> // Returns >= 0 for a processor id
>> // -1 if getcpu syscall is not supported
>> jint os::get_processor_id() {
>> unsigned int cpu = 0;
>> if (syscall(SYS_getcpu, &cpu, NULL, NULL) != -1) {
>> assert(cpu >= 0, "negative CPU id");
>> return (jint) cpu;
>> }
>> else {
>> return -1;
>> }
>> }
>>
>>
>> 64-bit: (sample from Novell/SuSE folk)
>>
>> #include <asm/vsyscall.h>
>>
>> #ifndef __NR_vgetcpu
>> #define __NR_vgetcpu 2
>> #endif
>>
>> int mygetcpu (unsigned *cpu, unsigned *node)
>> {
>> int (*p) (unsigned *cpu, unsigned *node, void *unused);
>> p = (void*)VSYSCALL_ADDR(__NR_vgetcpu);
>> return p (cpu, node, NULL);
>> }
>>
                                     
2011-09-06
EVALUATION

See main CR
                                     
2011-09-12



Hardware and Software, Engineered to Work Together