Нумерация ЦП 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?

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

Прекратите гадать и 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] дает иерархическое представление о процессорных отношениях.

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

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