SMP: Режим NUMA

Так если несколько отдельных процессоров каждый со своей памятью это в любом случае numa, не? А переключение это какой-нибудь костыль для венды.

Включаем, т.к. оно включено по дефолту =)
Отключать вряд ли имеет смысл, разве что подкрутить NUMA Group Size Optimization для не NUMA-aware софта, если того рекомендует вендор.

Во-первых, сейчас честных SMP не осталось в природе от слова совсем.

Во-вторых, что касается указанной настройки, так это сделано для венды, т.к. там есть такой костыль как Kernel Groups (Kgroups). Изначально венда умела только 64 логических процессора. Потом, чтобы это обойти придумали эти самые группы, каждая из которых имела аналогичное ограничение, зато самих группы было уже несколько. Так вот какой-то старый софт немного не в курсе, а потому продолжает жить в пределах одной группы. Это приводит к невозможности задействовать все ядра, а потому нужно настройку NUMA отключать, иначе венда криво формирует группы. Как-то так... Можно почитать всякую ерунду типа Microsoft KBA 2506384.

Мне думается, что для линукса это неактуально. А потому поддержу предыдущего оратора, рекомендующего всё включить. Пусть БИОС сообщает труЪ ОСи правду.

Я думал, что настройка в биосе как-то влияет на настройки контроллера памяти.

Теоретически оно должно было влиять на скорость работы процессора со своей памятью и «чужой», что подтверждалось в одной статье опубликованной несколько лет назад. Правда там тестирование велось под оффтопиком.

Пока машина находится на стадии тестирования есть возможность менять настройки.

Я нашел у интела утиль для имерения скорости работы с памятью, т.ч. можно посмотреть на реальные цифры.

Если бы можно было вишмастетром убрать недостаток медленного доступа к чужой памяти думаешь кто-то бы заморачивался работать без него?

Эта настройка не ускоряет доступ к памяти, она тормозит его всем, чтоб одинаковый был (ака синхронный режим работы кэша(шины?), тот еще гемморой, -5/15% производительности для задач которым безразлична NUMA/которые для нее сделаны и очень маленький прирост приложениям неумеющим в нее)

Есть утиль mlc с intel.com

Первый запуск - NUMA в биосе отключена, ядро ничего не знаяет про NUMA

Второй запуск - NUMA в биосе включена и в ядре включены

CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
CONFIG_ACPI_NUMA=y

Результаты в режиме NUMA отмечены '>'

Полезность режима NUMA для меня пока не очень очевидна.

в п.3 получется дикий провал производительности при обращении в чужую память.

Но пункты 2 и 4 показывают повышение производительности со своей памятью +25%

Может я чего не замечаю ?

1)
Intel(R) Memory Latency Checker - v3.5
Measuring idle latencies (in ns)...
           Memory node  
Socket       0       1
     0   102.7   102.7
     1   111.8   111.9

>            Numa node
>Numa node   0       1
>     0   80.8   130.9
>     1  131.7    80.6

2)
Measuring Peak Injection Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads        :      76654.6
3:1 Reads-Writes :      79478.0
2:1 Reads-Writes :      80584.8
1:1 Reads-Writes :      82212.4
Stream-triad like:      69073.8

>ALL Reads        :      96624.9
>3:1 Reads-Writes :      93314.0
>2:1 Reads-Writes :      93447.6
>1:1 Reads-Writes :      89570.4
>Stream-triad like:      83472.0

3)
Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
        Memory node
Socket       0       1
    0  44780.9 44849.0
    1  44754.7 44840.5
                Numa node
>Numa node   0       1
>   0  48283.8  7990.1
>   1   7958.8 48255.2

4)
Measuring Loaded Latencies for the system
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Inject  Latency Bandwidth
Delay   (ns)    MB/sec
==========================
 00000  205.10    76836.3
 00002  204.29    77050.7
 00008  201.66    76724.1
 00015  199.14    76057.6
 00050  184.53    74839.3
 00100  166.11    74268.4
 00200  126.32    47072.8
 00300  117.88    32286.9
 00400  114.91    24661.2
 00500  112.65    19977.9
 00700  110.21    14548.5
 01000  108.34    10421.9
 01300  107.35     8178.6
 01700  106.37     6410.9
 02500  105.06     4567.3
 03500  104.24     3445.0
 05000  103.70     2600.6
 09000  103.28     1722.6
 20000  103.14     1117.2

>Delay   (ns)    MB/sec
>==========================
> 00000  180.18    97476.3
> 00002  180.08    97327.4
> 00008  179.40    97338.2
> 00015  178.55    97434.4
> 00050  167.97    96942.6
> 00100  121.95    83691.2
> 00200  100.86    47146.4
> 00300   93.38    32429.8
> 00400   89.69    24814.6
> 00500   88.51    20126.1
> 00700   85.47    14708.5
> 01000   83.51    10589.0
> 01300   82.51     8349.0
> 01700   81.62     6588.1
> 02500   80.62     4750.4
> 03500   80.00     3628.2
> 05000   79.50     2788.3
> 09000   79.03     1911.8
> 20000   78.72     1309.3

Второй пункт с 76654.6 до 96624.9 вырос, а это грубо говоря +25% к общей пропускной способности при условии лазания в локальную для ноды память память.

да, это хорошо, но 5-ти кратное падение скорости в п.3 меня сильно удивило.

Т.е. если планировщик не будет допускать запуска процесс на чужой ноде, то все должно быть лучше чем в UMA режиме.