> И всё это даёт снижение задержек аж на 0.001% на фоне общего времени ответа приложения.

70%-130% задержек для IO: https://shbakram.github.io/assets/papers/akram-caos12.pdf

И всё потому что вы, как и многие не понимают проблематику гетерогенных компьютеров (несимметричные ядра в одном CPU) и современных многопроцессорных систем (ccNUMA).
https://www.cse.wustl.edu/~angelee/cse539/papers/numa.pdf

Поймите, сама концепция Shared Memory традиционная для UNIX из 70-х умерла вместе с последним Pentium 4. А вместе с ней померли традиционные SMP-системы (симметричная многопроцессорность). У вас больше нет северного моста к которому подключается RAM, все процессоры и высокоскоростные сопроцессорные шины. Сейчас уже не 2007-й. Теперь каждый процессор имеет свой набор периферийных устройств, свой набор RAM и представляет собой NUMA-узел. Узлы связаны интерконнект-шиной, которая нужна только для соблюдения когерентности кэша. Кэш третьего уровня при этом используется как буфер с каждой стороны для межпроцессорной передачи данных.

Нету никакой "быстрой" общей памяти, который процессы могут использовать через системные вызовы fork или clone. Если данные шли по сети или из стораджа на процессор CPU1, а дочерний процесс находится на CPU2, то весь этот набор данных не просто займет интерконнект-шину, но еще и создаст паразитную нагрузку на CPU1.
И не забудьте что у вас там с контекстами исполнения! Receive Datapath - это вообще-то I/O, которое обрабатывается драйверами в привилегированном режиме. NIC и HBA делают прерывание для приёма. Ваш юзерспейс на CPU1 и на CPU2 должен будет уступить процессорное время для этой передачи. Вы понимаете серьёзность того что я говорю? OpenMP знаете что такое (модель fork-join)? Ну так вот забудьте про это. Они там вроде обновили спецификацию, но мне еще предстоить увидеть OpenMP софт для Linuxб который нативно поддерживает NUMA API на стороне приложения.

> Круто, да.

Вы действительно не увидите разницу в производительности, если используете продукты вроде nginx или postgresql. Причем наоборот, возможны конфигурации, когда виртуалка с postgresql будет быстрее чем физический сервер. Но это проблема самих программ, которые не умеют оптимально работать на архитектуре ccNUMA (Xeon Scalable, AMD Epyc). Все продукты, кто используют shared memory лучше виртуализовать, а все кто представляет архитектуру аналогичную initd, умеют опрашивать аппаратную топологию, спавнить рабочие процессы и рулить передачей данных и кэшем в NUMA-системе лучше ставить на физику. Вот за этим и нужен IIS.

> Потому что в системе из 200 сервисов, написанных 60 разными командами, никто не будет наяривать на снижение задержек на пару наносекунд.

Когда люди применяют микросервисную архитектуру они по умолчанию готовы снижать производительность в десятки раз подарив её сетевым задержкам, медленным объектым хранилищам и готовы куски кода уложить в облако. Работа в стиле: нам нужно формировать квартальный отчет, давайте арендуем мощности в клауде высчитаем его там и потом вернем мощности обратно. Не все фирмы так делают.

А вообще когда мы говорим про сторадж, то там задержка в пару миллисекунд может выливаться в 100 кратное снижение производительности всего приложения.

Вам нужна симметрия и выравнивание устройств по NUMA и затем вам нужна поддержка NUMA в ваших приложениях:
https://cdrdv2-public.intel.com/782330/782330_Performance_Im...
Но в мире Linux люди либо не образованы, либо бредовые фанатики... Я же помню в конце нулевых пылкие презентации академических линуксоидов, рассказывающих на конференциях "NUMA не взлетит", "NUMA слишком сложна", "NUMA не нужна". И вот в 2024-ом году у нас все процессоры построены на NUMA причем то что у вас он 1 ничего не гарантирует: https://lenovopress.lenovo.com/lp1499.pdf

Сейчас в общем случае у вас есть 4 DRAM контроллера на сокете, но не все процессорные ядра могут получить к ним доступ с одинаковой скоростью. С одной стороны у вас есть ядра которые далеко от конкретного контроллера, с другой стороны у вас есть ядра, которые вообще не могут собирать данные из RAM и должны быть сгруппированы в кластер с тем ядром котороt может. Особенно хорошо будет это видно на всяких 128-ядерных AMD EPYC, в которых реальных ядер от силы 16 в зависимости от модели, а остальные - всего навсего потоки исполнения. Раньше для этого использовали SMT/HyperThreading, но эта технология проклята, спекулятивное выполнение слишком опасно для ряда задач повышает производительность до +25%, а для других снижает на -15%. В условиях когда в пятом поколении у вас clock разный на разных ядрах у вас по умолчанию процессор хочет работать в режиме Sub-NUMA Clustering, когда один SoC предствляется двумя или четырьмя узлами NUMA в системе. А вся разница между кластерными режимами в принципах маппинга кэша к RAM. И не забывайте про PCI Express и MMIO. Периферийные устройства на таком процессоре цепляются к "производительным" ядрам и мапятся в их областях памяти для организации receive datapath. Остальные узлы NUMA не имеют прямого доступа, если включен SNC, только через L3-кэш.

Всё это нужно знать если вы работаете с:
- HPC
- СУБД
- строите инфраструктуру виртуализации
Если же вы "пользователь" кубернетиса, то вам это знать не надо. Дядя инженер, который настраивал вам облако своё или покупное делает это вместо вас.

Проблема в том, что ОС Windows и её IIS в частности всё это умеет из коробки прямо на бареметале, а с Linux всё как всегда:
- ядро всё умеет, ну почти всё... то есть сторадж там фиговый, и сеть тонна легаси, когда все типы синтетических ускорений ввендорских драйверах, которыми нужно рулить через DPDK, но ccNUMA оно умеет и отдаёт в юзерспейс правильно.
- в юзерспейсе есть исторически не адлаптированный софт, которые не умеет с этим работать
- базилион дистрибутивов, которые отказываются внедрять базовую поддержку в юзерспейс и пользоваться этим.
То есть если вы не энтерпрайз, а какой-нибудь амазон или гугл, то вы можете собрать собственный дистрибутив под правильное железо и построить поверх него своё облако и свою инфраструктуру. Если вы обычный энтерпрайз и вам нужны физические сервера у вас Microsoft и его продукты, они работают. Если вы используете Linux в ентерпрайзе средней руки, вам нужно поставить Hyper-V или ESXi и виртуализировать в нем всё так, чтобы в каждой виртуалке был только один узел NUMA и тогда можно работать. Или вы думаете что пресловутые контейнерные среды вроде Kubernetes способны заниматься планированием ресурсов контейнеров по NUMA на бареметале? Спойлер: нет. Их оттого и ставят внутрь виртуалок.