How to determine the number of cpu/cores in redhat linux.

Matty Sarro msarro at gmail.com
Tue Aug 2 17:33:34 UTC 2011


On Tue, Aug 2, 2011 at 1:23 PM, Chi Chan <chichan2008 at gmail.com> wrote:
> It's better to get hwloc (Portable Hardware Locality library & utils)
> to detect hardware threads, cores, sockets. You can get a graphical
> representation of the machine, or you can get text or XML output if
> you want:
>
> http://www.open-mpi.org/projects/hwloc/doc/v1.2/emmett.png
>
> Hwloc is also a programming library that is used by Open Grid
> Scheduler (the open source version of Sun Grid Engine & Oracle Grid
> Engine), Torque scheduler, and various MPI libraries (OpenMPI,
> MVAPICH2 & MPICH2) in supercomputing. Hardware architecture has become
> very complicated and the output of /proc/cpuinfo is way too confusing
> IMO!
>
> You can download the loadcheck util from the Open Grid Scheduler hwloc
> page and run it to get the topology string. For example, "SCTTCTT"
> means 1 socket (S), 2 cores (C), and in total 4 threads (T):
>
> http://gridscheduler.sourceforge.net/projects/hwloc/GridEnginehwloc.html
>
> See also:
> http://www.open-mpi.org/projects/hwloc/
> http://www.rce-cast.com/Podcast/rce-33-hwloc-portable-hardware-locality.html
>
> --Chi
>
>
>
> On Tue, Aug 2, 2011 at 11:27 AM, unix syzadmin <unixsyzadmin at gmail.com> wrote:
>> hi,
>>
>> We have purchased a dell R710 and run redhat linux on it.
>> We want to determine the the number of physical sockets and cores and
>> hyperthreads on this server.
>>
>>
>> # dmidecode -t 4 | grep CPU
>>        Socket Designation: CPU1
>>        Version: Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
>>        Socket Designation: CPU2
>>        Version: Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
>>
>>
>>
>> *** excerpts from /proc/cpuifno ***
>>
>> processor: 0    physical id: 1    core id: 0    cpu cores: 6
>> processor: 1    physical id: 0    core id: 0    cpu cores: 6
>> processor: 2    physical id: 1    core id: 1    cpu cores: 6
>> processor: 3    physical id: 0    core id: 1    cpu cores: 6
>> processor: 4    physical id: 1    core id: 2    cpu cores: 6
>> processor: 5    physical id: 0    core id: 2    cpu cores: 6
>> processor: 6    physical id: 1    core id: 8    cpu cores: 6
>> processor: 7    physical id: 0    core id: 8    cpu cores: 6
>> processor: 8    physical id: 1    core id: 9    cpu cores: 6
>> processor: 9    physical id: 0    core id: 9    cpu cores: 6
>> processor: 10    physical id: 1    core id: 10    cpu cores: 6
>> processor: 11    physical id: 0    core id: 10    cpu cores: 6
>> processor: 12    physical id: 1    core id: 0    cpu cores: 6
>> processor: 13    physical id: 0    core id: 0    cpu cores: 6
>> processor: 14    physical id: 1    core id: 1    cpu cores: 6
>> processor: 15    physical id: 0    core id: 1    cpu cores: 6
>> processor: 16    physical id: 1    core id: 2    cpu cores: 6
>> processor: 17    physical id: 0    core id: 2    cpu cores: 6
>> processor: 18    physical id: 1    core id: 8    cpu cores: 6
>> processor: 19    physical id: 0    core id: 8    cpu cores: 6
>> processor: 20    physical id: 1    core id: 9    cpu cores: 6
>> processor: 21    physical id: 0    core id: 9    cpu cores: 6
>> processor: 22    physical id: 1    core id: 10    cpu cores: 6
>> processor: 23    physical id: 0    core id: 10    cpu cores: 6
>>
>> >From what i understand we have 2 physical CPU sockets, each with 6 cores, so
>> a total of 12 cores right?
>> I guess with hyperthreading this appears to be 24 logical cpu's right?
>>
>> I came to this conclusion on the following facts:
>> 1. any cpy with the same "physical id" are cores in the same socket.
>> 2. any cpu with the same "core id" are hyperthreads in the same core.
>>
>>
>> Thanks,
>> --
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
>>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>

Any reason not to just check /proc/cpuinfo?
Sorry, catching on to this a bit late.




More information about the redhat-list mailing list