Нумерация процессоров NUMA в Linux

У меня есть доступ к двум серверам NUMA. Один из них - Dell R720 и имеет следующие процессоры:

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

Другой - HPE DL360 Gen8 и имеет следующие процессоры:

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

На работе, где у нас много серверов HPE Gen9, я привык к нумерации ЦП (socket0, socket1, socket0 HyperThreads, socket1 HyperThreads). Похоже, что HPE DL360 Gen8 использует эту нумерацию:

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

Но сервер Dell R720 использует другую нумерацию:

$ 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

Мой вопрос, что вызывает эту разницу? Серверы имеют две слегка отличающиеся версии ядра:

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

Это вызвано разными версиями ядра? Или разными процессорами? Или разными материнскими платами / BIOS ами?

Изменить: Я обновил ядра на обеих машинах и перезагрузил, так что теперь обе машины используют точно одинаковую версию ядра. Тем не менее, разница все еще есть.

Источник

2 ответа

Прекратить разборки и uniq и беги lscpu а также lstopo --of png > server.png и визуализировать результаты...

[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

Источник

lscpu [1] будет более кратко выражать макет numa каждой системы. lstopo [2] дает иерархическое представление отношений процессора.

Перечисление определяется CPU + BIOS + ядро. На высоком уровне материнская плата имеет разные сокеты для 0 и 1, она всегда запускает 0. Процессор в сокете 0 затем запускает ядро ​​0 по определенному адресу и запускает BIOS, который затем перечисляет логические процессоры на этом чипе и дополнительные процессоры. (возможно, не в этом порядке) [3]. BIOS передает данные перечисления в ОС по мере необходимости, но ОС свободна для нумерации процессоров по своему усмотрению (представьте, что процессоры с горячей заменой делают с нумерацией).

Если вы беспокоитесь о сходстве и кешировании, то это полезное число для использования apicid. Битовое поле должно быть определено так, чтобы наиболее близкие друг к другу запоминающие устройства / кеши имели числовые близкие значения, упорядочивая биты Socket | Core | SMT. Ширина этих полей не фиксирована, поэтому вы не можете рассчитывать на то, что LSB всегда будет означать SMT, у него может не быть SMT, и этот бит является частью идентификатора ядра.

Источник
Другие вопросы по тегам