Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] CPU Model and type
From: TERRY DONTJE (terry.dontje_at_[hidden])
Date: 2011-09-16 11:50:03

> On 9/14/2011 5:54 AM, Brice Goglin wrote:
>> Le 13/09/2011 22:06, TERRY DONTJE a écrit :
>>> On 9/13/2011 9:54 AM, Brice Goglin wrote:
>>>> Le 13/09/2011 21:51, TERRY DONTJE a écrit :
>>>>> Both type and model are character strings. An example of what I
>>>>> currently store in the sysinfo structures are:
>>>>> type = "SPARC"
>>>>> model = "SPARC64_VI"
>>>>> Other values for model are "T1", "T2", "SPARC64_VII"...
>>>> What about Solaris on non-sparc machines ?
>>> Looks like the type is an empty string and model is "i86pc" in one case.
>>> These are basically values that come from calls to solairs sysinfo.
>> Type doesn't seem that helpful then. We already have the architecture
>> (taken from uname) in the machine attribute.
> Yeah, I guess Solaris is a little biased :-/.
>> I think you should just put model in the CPUModel info attribute. I
>> wil do the same for Linux and add the vendor to "CPUVendor" when
>> available, we'll get something like:
> So you are saying to add the a CPUModel and CPUVendor info to a socket
> object as we discussed earlier, right?
>> CPUVendor=GenuineIntel
>> CPUModel=Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
>> or
>> CPUVendor=AuthenticAMD
>> CPUModel=AMD Opteron(tm) Processor 6174
>> or
>> CPUModel=Alpha EV68CB
>> or
>> CPUModel=POWER7 (architected), altivec supported
>> or
>> CPUModel=Cell Broadband Engine, altivec supported
>> or
>> CPUModel=ARMv7 Processor rev 1 (v71)
> or
> ...
Brice, I started actually working on the SPARC detect code and a couple
things became obvious to me. First I really meant for CPUVendor to be
CPUType ala SPARC, i386, Alpha, Power. And the CPUModel be the fully
described model or brand-string like "SPARC64_VI", "AMD Opteron(tm)
Processor 6174", etc.

I really do not want to be using CPUVendor because SPARC is the
Processor type not vendor or manufacturer and even though I could force
CPUVendor to be SPARC but I feel we would regret doing so if ever we
wanted to truly key off on the CPUVendor for SPARC type processors.

So can we go back to using CPUType and can you populate it with the type
value instead of vendor?

In looking through my detect code I also figured recalled that it never
was compiled on non-sparc machines thus the weird values I was quoting
for CPUType and CPUModel for x386 based machines. I am going to rework
the code so it produces correct values when ran under Solaris on both
SPARC and i386 type processors. For i386 I expect to have values as such:

CPUType = i386
CPUModel = Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz

Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.781.442.2631
Oracle *- Performance Technologies*
95 Network Drive, Burlington, MA 01803
Email terry.dontje_at_[hidden] <mailto:terry.dontje_at_[hidden]>