Numeração da CPU NUMA no Linux

3

Eu tenho acesso a dois servidores NUMA. Um deles é o Dell R720 e tem essas CPUs:

$ cat /proc/cpuinfo |grep Xeon|sort|uniq -c
     24 model name  : Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz

O outro é um HPE DL360 Gen8 e tem essas CPUs:

$ cat /proc/cpuinfo |grep Xeon|sort|uniq -c
     24 model name  : Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz

No trabalho em que temos muitos servidores HPE Gen9, tenho estado acostumado a numerar CPU (socket0, socket1, socket0 HyperThreads, socket1 HyperThreads). Parece que o HPE DL360 Gen8 usa essa numeração:

$ cat /proc/cpuinfo |grep physical.id|uniq -c
      6 physical id : 0
      6 physical id : 1
      6 physical id : 0
      6 physical id : 1

Mas o servidor Dell R720 usa numeração diferente:

$ cat /proc/cpuinfo |grep physical.id|uniq -c
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1
      1 physical id : 0
      1 physical id : 1

Minha pergunta é: o que causa essa diferença? Os servidores têm duas versões de kernel ligeiramente diferentes:

Dell R720:

$ uname -a
Linux dell 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

HPE DL360 Gen8:

$ uname -a
Linux hpe 4.11.0-14-generic #20~16.04.1-Ubuntu SMP Wed Aug 9 09:06:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Isso é causado por diferentes versões do kernel? Ou por CPUs diferentes? Ou por diferentes motherboards / BIOSes?

Editar: eu atualizei os kernels em ambas as máquinas e reiniciei, então agora ambas as máquinas usam exatamente a mesma versão do kernel. No entanto, a diferença ainda está lá.

    
por juhist 16.12.2017 / 13:38

2 respostas

2

Pare o grepping e uniq e execute lscpu e lstopo --of png > server.png e visualize os resultados ...

[root@LA_Specialty ~]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24
On-line CPU(s) list:   0-23
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 62
Model name:            Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
Stepping:              4
CPU MHz:               3501.000
BogoMIPS:              7013.88
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-5,12-17
NUMA node1 CPU(s):     6-11,18-23

    
por 16.12.2017 / 16:19
1

lscpu [1] expressará mais concisamente o layout numa de cada sistema. lstopo [2] fornece uma visão hierárquica das relações do processador.

A enumeração é determinada pelo kernel CPU + BIOS +. Em um nível alto, a placa-mãe tem soquetes diferentes para 0 e 1, sempre inicia 0. A CPU no soquete 0 então inicia o núcleo 0 em um determinado endereço e inicia o BIOS, que então enumera as CPUs lógicas neste chip e CPUs adicionais (possivelmente não nessa ordem) [3] . O BIOS passa os dados de enumeração para o sistema operacional conforme necessário, mas o SO está livre para numerar as CPUs da maneira que quiser (imagine o que os processadores hotplugging fazem na numeração).

Se você estiver preocupado com afinidades e caching, o apicid é um número útil a ser usado. O bitfield deve ser definido de modo que as memórias / caches mais próximas tenham apicids que sejam numericamente próximos, ordenando os bits Socket | Core | SMT. As larguras desses campos não são fixas, então você não pode contar com o LSB para sempre significar SMT, ele pode não ter SMT e este bit é parte do ID do núcleo.

    
por 16.12.2017 / 16:15