![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В течении долгого времени идея микроядерной архитектуры ОС (где в пространстве ядра находится только заглушка для обмена сообщениями, а вся традиционная ядерная функциональность вынесена в отдельные процессы) критиковалась из-за сниженной производительности. Дескать, слишком долго это — тратить время на memcpy() параметров и результатов каждого системного вызова, лучше когда вся ядерная память всегда "под рукой". "Все эти ваши L4, Hurd и Minix страшно далеки от народа, Unix и Windows NT во все поля, дёшево и быстро" — говорили они.
Хотя если много-много запросов загнать в преаллоцированный кольцевой буфер, а потом обслужить их все "одним махом", как это делается в паравиртуальных драйверах virtio, или в netmap, или в RIO API, или в DPDK/SPDK, то можно даже получить выигрыш по производительности (теряем время на копировании, экономим на переключении контекста).
Та же идея относительно "асинхронных системных вызовов" рассматривалась в статье FlexSC: Flexible System Call Scheduling with Exception-Less System Calls авторам которой удалось получить прирост производительности на 116% для MySQL и 40% для Apache. Кстати, очень хорошая статья, на которую следует посмотреть свежим взглядом, учитывая опыт нынешнего "Интелпокалипсиса".
Из-за уязвимостей Meltdown и Spectre, мы одним большим прыжком приблизились к миру операционных систем, где привилегированный системный код выполняется на выделенных ядрах процессора, а пользовательский код — на всех остальных ядрах процессора. А в микроядре остаётся только обмен сообщениями и переключение задач.
Потому что KPTI патчи, сбрасывающие CR3+TLB на каждом системном вызове (всё-таки Линус Торвальдс прав, FUCKWIT или UASS звучит лучше) с их налогом на производительность в 50% — это временная затычка. Потому что retpoline-патчи для clang, способные "отучить" процессор от предсказания ветвлений ценой снижения производительности генерируемого кода в тех же 2 раза — это временная затычка. Потому что готовящиеся сейчас обновления микрокода для всех поддерживаемых процессоров с целью сброса статистики для предсказания ветвлений, который (сброс) должен выполняться при каждом пересечении границы ядро/юзерспейс — это временная затычка.
Intel, AMD, ARM и все остальные не переделают выпущенные за последние 20 лет процессоры и никогда не откажутся от кэшей, опережающего исполнения и предсказания ветвлений. Не может быть так, чтобы следующее поколение Xeon'ов и Epyc'ов работало со скоростью Pentium II. Meltdown и Spectre — это только цветочки, потому что идея творческого совмещения branch prediction poisoning, speculative execution и cache timing attacks прочно завладеет умами security-исследователей на ближайшее десятилетие. А это значит, что единственный выход — это разнести "хороший" и "плохой" код по разным ядрам (cores), чтобы микроархитектурные утечки (состояние кэша, статистика для предсказания ветвлений) между "хорошим" и "плохим" кодом были невозможны.
Микроядерная архитектура операционных систем победила монолитную и монолитную-с-модулями. Уже сейчас ясно, что цена "KPTI + retpoline + бестолково частых сбросов branch prediction статистики через микрокод" превышает цену микроядерного IPC.
Хотя если много-много запросов загнать в преаллоцированный кольцевой буфер, а потом обслужить их все "одним махом", как это делается в паравиртуальных драйверах virtio, или в netmap, или в RIO API, или в DPDK/SPDK, то можно даже получить выигрыш по производительности (теряем время на копировании, экономим на переключении контекста).
Та же идея относительно "асинхронных системных вызовов" рассматривалась в статье FlexSC: Flexible System Call Scheduling with Exception-Less System Calls авторам которой удалось получить прирост производительности на 116% для MySQL и 40% для Apache. Кстати, очень хорошая статья, на которую следует посмотреть свежим взглядом, учитывая опыт нынешнего "Интелпокалипсиса".
Из-за уязвимостей Meltdown и Spectre, мы одним большим прыжком приблизились к миру операционных систем, где привилегированный системный код выполняется на выделенных ядрах процессора, а пользовательский код — на всех остальных ядрах процессора. А в микроядре остаётся только обмен сообщениями и переключение задач.
Потому что KPTI патчи, сбрасывающие CR3+TLB на каждом системном вызове (всё-таки Линус Торвальдс прав, FUCKWIT или UASS звучит лучше) с их налогом на производительность в 50% — это временная затычка. Потому что retpoline-патчи для clang, способные "отучить" процессор от предсказания ветвлений ценой снижения производительности генерируемого кода в тех же 2 раза — это временная затычка. Потому что готовящиеся сейчас обновления микрокода для всех поддерживаемых процессоров с целью сброса статистики для предсказания ветвлений, который (сброс) должен выполняться при каждом пересечении границы ядро/юзерспейс — это временная затычка.
Intel, AMD, ARM и все остальные не переделают выпущенные за последние 20 лет процессоры и никогда не откажутся от кэшей, опережающего исполнения и предсказания ветвлений. Не может быть так, чтобы следующее поколение Xeon'ов и Epyc'ов работало со скоростью Pentium II. Meltdown и Spectre — это только цветочки, потому что идея творческого совмещения branch prediction poisoning, speculative execution и cache timing attacks прочно завладеет умами security-исследователей на ближайшее десятилетие. А это значит, что единственный выход — это разнести "хороший" и "плохой" код по разным ядрам (cores), чтобы микроархитектурные утечки (состояние кэша, статистика для предсказания ветвлений) между "хорошим" и "плохим" кодом были невозможны.
Микроядерная архитектура операционных систем победила монолитную и монолитную-с-модулями. Уже сейчас ясно, что цена "KPTI + retpoline + бестолково частых сбросов branch prediction статистики через микрокод" превышает цену микроядерного IPC.
