Часть 12. Немного про CPU
Часть 12. CPU type
Часть 12. Hyper-threading и безопасность
Часть 12. Hyper-threading и скорость

Часть 12. CPU type

В свойствах виртуальной машины, а может где-то еще, можно настроить CPU type. Причина появления этой настройки понятна, совместимость разных поколений процессоров.
Разные поколения процессоров имеют разные инструкции. Соответственно, чтобы приложение внутри виртуальной машины после миграции не обнаружило, что на новом физическом сервере более старый процессор не умеет выполнять какую-то инструкцию, на исходном сервере операционной системе (и приложению в ней) заранее сообщается, что там стоит «виртуально более старый процессор».
Для ESXi это называется Enhanced vMotion Compatibility (EVC). И отдельно можно поиграть в CPU Compatibility Masks.
Для Hyper-V это называется Processor Compatibility Mode (CompatibilityForMigrationEnabled)
В некоторых задачах (AES) это может дать х3 снижение производительности, в других почти незаметно.

Можно ли жить без этой настройки ? Можно, и желательно держать в кластере (в любом) одинаковые сервера – не только с одинаковыми CPU, но и с одинаковыми версиями BIOS, и с одинаковой прошивкой микрокодов для CPU в этом BIOS. Не потому, что это обязательно, а потому, что так меньше возможных проблем. И плюс исправления к CPU иногда выходят, не забывайте ставить.

Можно ли мигрировать VM «без этой настройки» ?
Выключенные однозначно да,  у всех.
Включенные в ESXi – нет.
Включенные в Hyper-V – нет, они с и включенной настройки иногда не мигрируют, хотя и по другим причинам.
Включенные в proxmox – я не пробовал.

Можно ли мигрировать между Intel и AMD ? В рамках домашних лабораторий и учебных стендов можете делать что угодно. В рабочей среде так делать не надо, даже когда режим совместимости заранее выставлен на минимальный минимум. Между Intel и AMD мигрировать в выключенном виде, так спокойнее.

Часть 12. Hyper-threading и безопасность

Когда-то давно, в 2018 году, для Intel нашли уязвимость L1 Terminal Fault (L1TF). Для устранения этой уязвимости, от момента обнаружения до момента выхода исправления, предлагалось, в том числе,:

The L1TF vulnerability introduces risk that the confidentiality of VBS secrets could be compromised via a side-channel attack when Hyper-Threading (HT) is enabled, weakening the security boundary provided by VBS. Even with this increased risk, VBS still provides valuable security benefits and mitigates a range of attacks with HT enabled. Hence, we recommend that VBS continue to be used on HT-enabled systems. Customers who want to eliminate the potential risk of the L1TF vulnerability on the confidentiality of VBS should consider disabling HT to mitigate this additional risk.
Microsoft Guidance to mitigate L1TF variant

После выхода и применения исправлений предлагалось включить HT обратно

Important: Disabling Intel Hyperthreading in firmware/BIOS (or by using VMkernel.Boot.Hyperthreading) after applying vSphere updates and patches is not recommended and precludes potential vSphere scheduler enhancements and mitigations that will allow the use of both logical processors. Mitigation should be done by enabling the ESXi Side Channel Aware Scheduler (see below).
VMware response to ‘L1 Terminal Fault - VMM’ (L1TF - VMM) Speculative-Execution vulnerability in Intel processors for vSphere: CVE-2018-3646

Для проксмокса были те же рекомендации, и предупреждение, цитата

L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details
Problem/message L1TF CPU bug and data leak

На «сейчас», после обновлений «всего», я такой рекомендации, «выключать», не видел. По крайней мере, не видел на более-менее новых процессорах и версиях 8 и 9.

Часть 12. Hyper-threading и скорость

Hyper-threading is an Intel technology that exposes two hardware contexts (threads) from a single physical core. These threads are referred to as logical CPUs. It is a common misconception that hyper-threading doubles the number of CPUs or cores. This is simply not the case. Hyper-threading improves the overall host throughput from 10-30% by keeping the processor pipeline busier and allowing the hypervisor more opportunities to schedule CPU clock cycles and so you should definitely take advantage of hyper-threading by enabling it in the BIOS of the VM host machine.
SQL Server Best Practices, Part II: Virtualized Environments

Есть несколько бытовых мифов про влияние Hyper-threading на скорость VM

Миф первый. HT замедляет работу, потому что это не настоящее ядро.
Этот миф растет из общего непонимания, что такое «ядро», и как с ним работает операционная система. HT это вообще не ядро, это «нить» или «поток исполнения»

Cores are physical processing units.
Threads are virtual sequences of instructions given to a CPU.
Multithreading allows for better utilization of available system resources by dividing tasks into separate threads and running them in parallel.
Hyperthreading further increases performance by allowing processors to execute two threads concurrently.
What Are CPU Cores vs Threads?

Тут я совсем не уверен в том, как это работает с точки зрения именно планировщика по потокам. В общем виде работает это следующим образом:
В случае нормальной работы планировщика (process scheduler \CPU scheduler ), он распределит задачи сначала по 1 потоку на физическое ядро, то есть не «на задача будет выделено физическое ядро», а «задача будет назначена на первый входящий тред физического ядра».
Поэтому в общем случае у вас не будет какой-то мега нагрузки на CPU.
Но, если вы изначально рассчитывали на включение HT и удвоение производительности, то, конечно, забудьте.

Миф второй. У меня огромнейшая нагрузка, поэтому задача, поставленная не на физическое ядро, будет работать медленно.

Поскольку речь не идет про назначение на ядра, нужно понимать, что кроме задач «на CPU», то есть математики, есть задачи ожидания из «дальней» памяти, от дисков, от сети, от пользователя, итд. Все это время само «физическое» ядро будет ждать поступления команды, и нет никаких причин для не выполнения в это время задачи из второго потока.

Скорее всего, нет у вас такой нагрузки. Но, если вы считаете, что точно есть, ну что ж, выключайте. В некоторых случаях, если вам так будет спокойнее, и вы не готовы что-то численно измерять, то можете выключить. Или сказать что выключили, иногда «сказать, что выключили и ускорили, ничего не делая» ускоряет работу системы в 1.5 раза.

Миф третий. Надо просто дать побольше ядер.
Выдать можно. Планировщик хоста будет пытаться сбалансировать треды исполнения, потому что он ничего не знает про то, какие задачи исполняются внутри.
При этом, для некоторых, довольно специфичных задач, например в случае, если у вас есть DBA, ваш DBA знает что такое NUMA, ваш DBA не боится им пользоваться, и внутри VM стоит Microsoft SQL Server 2022 или Microsoft SQL Server 2025, то выделить VM «чуть больше» чем физических ядер, и покрутить настройки трансляции NUMA может быть полезным. Про SQL soft numa и релиз ноты вообще читать полезно, как и что-то типа SQL Server Best Practices, Part II: Virtualized Environments
В остальных сценариях не надо так делать. Например, у PostgreSQL может быть грусть и тоска

Реальная сложность для меня, это отсутствие в Linux параметра CPU ready в нужном мне виде. И это не Steal time, про это ниже.
В ESXi CPU ready есть, и виден через esxtop, и в некоторых сценариях необходимо уменьшить, именно уменьшить число vCPU - Lowering the number of vCPUs reduces the scheduling wait time
Читать по теме:

CPU Ready Time Issues in ESXi Environments Running SQL Server VMs
Determining if multiple virtual CPUs are causing performance issues
How CPU management works on VMware ESXi 6.7

Для Windows server 2025 были введены новые метрики - CPU jitter counters, CPU Wake Up Time Per Dispatch, CPU Contention Time Per Dispatch, детальнее смотрите в статье CPU oversubscription and new CPU jitter counters in Windows Server 2025.

Для libvirt  есть virt-top . Для поиска источника нагрузки на диски есть iotop и htop, оба кстати не установлены из коробки.
В теме Steal time monitoring есть отсылка на проект vmtop, но как его проверить на пригодность, и как он будет жить, не из коробки и с его зависимостями – мне не очевидно. Последний коммит в проект – 16 апреля 2024.

Из этой характеристики вырастает проблема с аналогом VMware DRS (Distributed Resource Scheduler) или Hyper-V Load Balancing, точнее SCVMM dynamic optimization, особенно если на это намазан толстый слой .. для ESXi  слой ESXi host group  и VM-Host affinity rule , для Hyper-V и SCVMM – слой VM Affinity  \ Anti-affinity и Fault domain.

То есть, функционал (некий! (TM)) в Proxmox есть, Proxmox introduces Cluster Resource Scheduler for Proxmox Virtual Environment 7.3, есть отдельно ProxLB

Отдельно надо сказать про мониторинг. Я не знаю, это в Zabbix так сделано, или в Linux, или не знаю где еще, но при включенном HT, при не понятно каких условиях, нагрузка CPU выглядит как «не выше 50%».

Часть 12. И про кластер

Самое неприятное в статье Cluster Manager, это то, что там все работает от root.
Второе, не самое приятное – Corosync.
Потому что под iSCSI отдельные интерфейсы дай, под Corosync – дай (Corosync network planning), плюс лимит в хостов 20, и новостями типа with over 50 nodes in production. Ну что такое 50 нод, это ж немного. Четыре корзины по 12 лезвий.

Часть 12.Подводя итог

Если открыть статью Bibliography, то окажется, что книга Wasim Ahmed. Mastering Proxmox - Third Edition. Packt Publishing - это 2017 год, The Debian Administrator's Handbook – 2021.
Литературы мало, на русском почти нет совсем (кроме разрозненных статей). Порог входа не то чтобы высокий, но выше, чем у Hyper-V. Части привычного функционала еще нет, или он реализуется посторонними проектами. Метрокластер не понятно, как на таком строить.
Кластерная файловая система под вопросами. 
Крутить локальные виртуалки – пойдет, и даже iSCSI будет работать. Провайдеры, опять же, всякие в наличии. Но это уже совсем другая история

Литература
QEMU / KVM CPU model configuration
Enhanced vMotion Compatibility (EVC) Explained
Как работает и как используется Enhanced vMotion Compatibility (EVC) в кластерах VMware vSphere
Impact of Enhanced vMotion Compatibility on Application Performance
Processor Compatibility Mode in Hyper-V
Processor compatibility for Hyper-V virtual machines
Performance Impact of Hyper-V CPU Compatibility Mode
Proxmox wiki Manual: cpu-models.conf
Proxmox wiki IO Scheduler
Proxmox wiki High Availability
Proxmox wiki Cluster Manager
Proxmox PVE Bibliography
Старая (2010) статья Multi-Core Scaling In A KVM Virtualized Environment
What is a vCPU and How Do You Calculate vCPU to CPU?
Hyper-V NUMA affinity and hyperthreading
VMware response to ‘L1 Terminal Fault - VMM’ (L1TF - VMM) Speculative-Execution vulnerability in Intel processors for vSphere: CVE-2018-3646 (55806)
Mitigation Instructions for CVE-2022-21123, CVE-2022-21125, and CVE-2022-21166 (VMSA-2022-0016) (88632)
Guidance for mitigating L1 Terminal Fault in Azure Stack
Microsoft Guidance to mitigate L1TF variant
Which process scheduler is my linux system using?
Completely Fair Scheduler and its tuning
Linux schedulers – overview
The Linux Scheduler a Decade of Wasted Cores
New EEVDF Linux Scheduler Patches Make It Functionally "Complete"
What Are CPU Cores vs Threads?
CPU oversubscription and new CPU jitter counters in Windows Server 2025

Что делает планировщик, точнее cpu scheduler, при стандартных настройках.
Планировщик старается выдать каждому процессу (каждой VM, за исключением World 0 , и то, если вы не лазали в minroot кривыми ручонками) равное количество процессорного времени.

Что произойдет, если у вас в системе 32 физических ядра, и вы выдали суммарно 32 vCPU core, скажем? 8 VM по 4 CPU core?  Ничего особенного, планировщик разложит задачи по физическим ядрам, и стандартные, не особо нагруженные VM, будут работать как работали. За, правда, исключением случая Storage space и storage space direct (S2D), там будет чуть сложнее. И с vSan не все так просто, но приемлимо.
Что произойдет, если у вас в системе те же 32 физических ядра, и вы выдали суммарно 96 vCPU core, скажем, 24 VM по 4 CPU core?  Тоже ничего особенного, планировщик разложит задачи по физическим ядрам, потом попытается разложить задачи по виртуальным ядрам, потом построит очередь, и будет, так или иначе, эту очередь выполнять. Для ежедневных сценариев и нормальных гипервизоров ситуация с переподпиской CPU 1:1.5 и до 1:3 по физическим ядрам находится между «нормальной» и «терпимой».

Уточнение. Правильнее сказать «годится для начала разговора и осмотра CPU ready». Потому что одно дело у тебя система, которая почти ничего не считает, но крутит данные в памяти, как не в себя, другое дело VDI, третье дело NTP или еще какой сервер, у которого 2 vCPU только из вежливости. Кроме просмотра CPU ready, еще надо смотреть co-stop (%CSTP).

Для VDI сценариев, где 99.99% времени система ждет, пока пользователь нажмет что-то на клавиатуре, нормально будет работать и 1:10.
Оговорка: конечно, не во всех сценариях, и не во всех гипервизорах. Для нагрузки, чувствительной к задержкам, c ESXi 5.5, есть режим Latency-Sensitive. Для VM размером в хост, тоже есть свои настройки. См. разделы литература ниже.

Что произойдет, если у вас в системе те же 32 физических ядра, и вы выдали суммарно 64 vCPU core, скажем по 48 vCPU 2 VM (#1, #2),  и по 8 еще оставшимся 4 (#3, #4, #5, #6)?  Напоминаю, всего у вас в системе 32 ядра / 64 потока.

Будет очень интересно, не переключайтесь

Допустим, планировщик начал с первой машины (VM #1). Первым делом планировщику надо дождаться, пока остальные пять сделают свои дела с CPU, или, пока не пройдет таймаут. Допустим, что планировщику и VM свезло, и Vm #1 полезла на 48 vCPU.
А 48 физических ядер нет. Есть 32. Надо выкидывать остальные задачи куда-то в кеш 2-3-N уровня. Освобождать весь кеш 32+16 потоков, и всякие регистры к ним еще раз. Выполнить сначала одно, потом второе, и при этом попытаться уложиться в таймслот. Начинается то, что зовется context switches. И это я еще не лезу в пособие по архитектуре HT, потому что я даже не представляю, как именно построены очереди исполнения и всякие регистры по отношению к HT и тому, что называется speculative execution.
Окей, худо-бедно выполнились, и !
И пришла беда, откуда не ждали. У Intel Xeon давно есть режим авторазгона. Одни ядра разгоняются, другие нет, в результате угадать, какие ядра останутся на 2.2 , какие захотят работать на 2.4, какие на 2.6 – невозможно. Со всеми последствиями для попытки поддержать синхронность выполнения задач на ядрах со стороны планировщика.
Со стороны почти любого мониторинга это выглядит так, что процессор ничего не делает, и это чистая правда.
Сделаем еще шаг назад. Кроме ядер, в работе фигурирует и оперативная память. И желательно, чтобы данные в памяти (в физической памяти) были поближе к нужному ядру. NUMA, non uniform memory access, в полном расцвете сил. Хорошо, что в этом сценарии она не работает.
Сделаем еще шаг назад. Процессор – это не только калькулятор, это еще и всякие EAX EBX ECX EDX, и прочие данные, и очень не хотелось бы, чтобы специально обученные злодеи выдернули из этих ESI EDI ваш пароль, или хеш от него. Ага, Meltdown и Spectre (там чуть сложнее, конечно).

Начинается шаг 2 - исполнение VM #2 еще на 48 ядер. Даже и не на 48, кстати.

Планировщик пытается сказать процессору «давай, исполняй».

Процессор пытается разогнаться, при этом выкинуть лишние данные из своих кешей, памяти, регистров, и так далее. Точнее, конечно, планировщик командует, ядра делают.
VM #2 пытается всеми своими 48 ядрами, с криками «мне положено, вас тут не стояло», залезть на 32 ядра. Может, успевает даже что-то выполнить на разогнанных ядрах. Может, нет. И планировщик начинает ее выгонять с ядер со словами «завтра досчитаешь, СЛЕДУЮЩИЙ», напевая под нос  What You Waiting For?

Шаг 3

На 32 ядра лезут оставшиеся 4 по 8, быстро исполняются, ну как могут, и на следующем шаге планировщик  опять пытается выполнить VM #1. Но VM 3, 4, 5, 6 работают за разное время, поэтому VM 1 придется подождать, пока выполнятся все задачи на всех ядрах, у всех машин, и только потом планировщик будет пытаться утрамбовать VM #1, примерно так же, как Lock, Shock and Barrel пропихивали Sandy Claws в трубу.

Все это время ядра не делают ничего. Ну как ничего. Сидят и курят.
С точки зрения мониторинга, загрузка на считающую часть процессоров - ноль.

Планировщик сидит, курит, и поет

Goodbye
Yes, it's time to say goodbye
Sad, I know, but, hey, you're done with living
It's time to give in
And go and so, goodbye

(но это не точно, может относится к этому более филосовски. Как говорилось, We all bloody die. Except this one here.)

Что сделали

Взяли, и вопреки всем крикам «да что вы делаете, как жить то» - отобрали у самых толстых машин, 1с кстати, лишние ядра. Все равно она ими пользоваться не умеет. И настройки в BIOS покрутили. И стало хорошо.

Литература

Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5

Режим высокой производительности для требовательных виртуальных машин в VMware vSphere 5.5 (Latency Sensitivity).

Performance Tuning for Latency-Sensitive Workloads VMware vSphere 8

Windows Server 2019 Hyper-V host behavior running in the minroot configuration

[Performance] Interpreting CPU Ready values

Нюансы CPU Ready

CPU oversubscription and new CPU jitter counters in Windows Server 2025

x86 Registers

Context Switches

High context switch rate

Infographics: Operation Costs in CPU Clock Cycles: Not all CPU operations are created equal

Context switch-Everything you need to Know

Side-channel aware scheduler (SCA) - SCAv2

Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors

Optimizing Networking and Security Performance Using VMware vSphere and NVIDIA BlueField DPU with BWI

Understanding ESXi CPU scheduling

Performance of vSphere 6.7 Scheduling Options

Performance Best Practices for VMware vSphere 8.0 Update 3

Maximizing VMware Performance and CPU Utilization

Why VMware Engineers Tell You to Right-size Your VMs: Becau$e Co-$top Will Co$t You Money

Soft-NUMA (SQL Server)

Which vSphere CPU Scheduler to Choose

Determining if multiple virtual CPUs are causing performance issues

PS. Логика Пикабу зачем-то советует тег "другой мир". Окей. Тега broadcom нет, тега Nutanix нет

то не видит RAID контроллер, то все вместе, а то вдруг все видит, но на этапе установки ругается на мои вшитые в образ VIB с драйверами ссылаясь на какие-то зависимости:

Этот момент мне несколько поднадоел и решил я в качестве эксперимента накатить последнюю версию Proxmox, вот как есть, без каких-либо изменений и она без проблем установилась на текущую конфигурацию, увидела и RAID контроллер и сетевую карту, да всё настолько легко прошло, что я решил перенести на неё все мои виртуалки. Собственно сам перенос из файла .ovf выполняется одной единственной командой qm importovf 103 /home/Win11/Win11.ovf local-lvm:

103 - идентификатор VM, /home/Win11/Win11.ovf - путь к файлу .ovf, local-lvm - путь к хранилищу на гипервизоре proxmox

В случае с Windows импорт я делал прямо из .ovf файла который получил путем экспорта с ESXi, там было достаточно заменить scsi0 на sata0 в конфигурационном файле /etc/pve/qemu-server/103.conf и добавить сетевой адаптер.

В итоге ОС запускается и работает без проблем:

А вот в случае, когда я переносил машину Debian с Home Assistant, первоначально у меня она была перенесена из .ovf в VMware Workstation, поскольку, пока я копался с настройкой Proxmox, надо было чтобы HA продолжал работать, затем когда всё готово было к переносу, я сделал экспорт Debian с HA и затем экспорт уже на Proxmox, всё завелось с полпинка, даже после проброса USB ZigBee Sonoff 3.0 dongle - не пришлось колдовать с Zigbee2MQTT, он заработал сразу. На волне успеха побежал импортировать свою виртуалку с Debian, которая с такой же лёгкостью не поднялась, а дело было в том, что на VM с HA у меня был BIOS, а на второй UEFI, тут то и зарылась проблема, понял я это не сразу и даже потратил немного времени, перенес виртуалку сначала в VMware Workstation, оттуда сделал экспорт, затем импорт в Proxmox и ничего не заработало, но оно и не удивительно. Теперь конкретнее, что необходимо было сделать если вы переносите таким способом VM Debian UEFI. После выполнения импорта на гипервизор в настройках виртуалки:

Сетевой адаптер добавить не забываем, они всегда слетают после импорта.

Далее необходимо запустить виртуалку и в консоли сразу же нажать ESC чтобы попасть в настройки UEFI, пройти по пути:

Далее пройти по пути до самого загрузчика:

Далее изменить загрузку по умолчанию:

виртуалка перезагрузится

ESXi670-202503001 | 04 MAR 2025 | Build 24514018
RN

Традиционно, на портале https://support.broadcom.com опять все сломали. Через Okta логин не работает, все не так, все не то.

Если пройти по прямой ссылке на скачивание, VMware-ESXi-8.0U3c-24414501-depot, то кнопки download пока нет. Или опять что-то поменялось в политике партии, или просто еще не выложили.
Скачивание через vSphere Lifecycle Manager (vLCM) не проверял.
Подождем.
В пиратке пока тоже ничего нет

Для 6.5 и 6.7 обновлений ESXi давно не было, для vCenter были, но давно:
6.7 / Build Number 24337536 - 2024-10-28
6.5 / Build Number 24045034 - 2024-07-04

Как и ранее, все обновления пока свободно доступны для скачивания на Broadcom Support Portal, за исключением того, что сам портал стал еще более кривым. С каждым разом все кривее и кривее.
И, как уже написал - Release notes переехали на https://techdocs.broadcom.com

В остальном у Broadcom все по прежнему – удаляют и удаляют старое.
Перед новым годом прислали сообщение про переактивацию аккаунта для Broadcom Support Portal с 21 января 2025.
Сейчас удаляют материалы по не поддерживаемым 6.5 и 6.7 – что то остается, что-то уже нет.
Удалили часть HCL / compatibilityguide, как будет работать [Skyline] Health Hardware compatibility для старого железа - не понятно (скорее всего – никак). Может, это и к лучшему – спасибо Linux community за удаление API vmklinux и переход на Native Device Driver.
Те, кому надо, и без меня знают про USB Network Native Driver for ESXi и Nested ESXi Virtual Appliance & USB Network Native Driver for ESXi for vSphere 8.0 Update 3.

У MS наконец-то (не следил, когда, может и очень давно) поменялись дистрибутивы для скачивания 2025 сервера без регистрации и смс.

Было 26100.1.240331-1435.ge_release_SERVER_EVAL_x64FRE_en-us.iso
MD5 8286AE65AB4D6FF2430B914D7901427B

Стало 26100.1742.240906-0331.ge_release_svc_refresh_SERVER_EVAL_x64FRE_en-us.iso
MD5 52D37544CA98287DD2B15F526EBFAFA5
SHA256 D0EF4502E350E3C6C53C15B1B3020D38A5DED011BF04998E950720AC8579B23D

Было 26100.1.240331-1435.ge_release_SERVER_EVAL_x64FRE_ru-ru.iso
MD5 CE0F3B7BD4B1E11A2D158B27E29DCD99

Стало 26100.1742.240906-0331.ge_release_svc_refresh_SERVER_...
MD5 3A2CBDB4FE9E7C0A7C530CD1AE732C0F
SHA256 15F31D0E4F7C5337732BA9629008E99501AAA5007D81A267A1D04F6DEB5571A6

Внутри  sources\install.wim\ - 4 дистрибутива, с обновлениями от сентября 2024, так что все равно надо обновляться.

Обещанную мега-скорость работы на NVME пока не проверял, еще не купил на домашний стенд.
Сразу отвечу на простой вопрос, как так, prox, windows, esxi ? Очень даже так, ESXi 7 и 8 по прежнему отлично загружается с USB флешки.

На рабочих стендах до нового года (с 28 января 2025), скорее всего, коллеги проверить "как стало" не успеют.

Чем еще запомнился 2024 год, так это переходом в Ubuntu 22 и Ubuntu 24.04 server на netplan, и этот его
/etc/netplan/99_config.yaml

Зачем так было делать, я так и не понял, и не я один.
Пришлось переписать много букв, и придется переписать еще больше.
Отдельно хотелось бы отметить по прежнему не очень хорошую работу и CFS, и EEVDF, особенно если у тебя 200+ ядер на хост. Что с этим делать, как нормально настроить Sub-NUMA, Hemisphere and Quadrant Modes, и EEVDF, пока никто не сознается, придется опять идти за советами на stack overflow и reddit.

Поплакал и хватит, за работу.

Концовка

Тут должна быть какая-то не скомканная концовка, но я ее так и не придумал.