>> нет, они просто деоптимизировали ядро.
> Для тех кому пох есть mitigations=off.нету. kpti=off (еще во времена когда всех остальных троянцев не было) тестировали лобастые пацаны в гугле. И намеряли аж >20% потери производительности по сравнению с кодом в котором просто не было еще никакого kpti. То есть совершенно чудовищную регрессию. И... пипл схавал и добавки просит.
Потом правда обо...сь и само это исследование гугль удалил - но ссылки на него ты еще мог бы найти если бы умел что-то кроме чатгопоты.
Т.е. проблема в том что ядро изуродовали _необратимо_ - ниасилив в условную компиляцию. Миллион каких-то фич, фичек и фитюлек, больщую часть которых ты даже навряд ли сможешь объяснить и они известны разьве что сотрудникам интела - пожалуйста, в виде параметров KConfig, а вот это ненужное счастье - даром и всем, чтоб никто не ушел.
> в АКТУАЛЬНОЙ версии ядер фиксы неслабо оптимизированы
ссылок на результаты теста _в_сравнении_с_неизуродованным_ядром_ а не с =off - разумеется не будет, потому что никто не посмел такие тесты проводить (да, интел прямо намекал чтоб так не делали - причем вот ровно после той истории со скидыванием CEO акций пока-не-подешевело). Верьте нам, мы мамой клянемся!
А на самом деле - сделали из очень плохо прям совсем никуда не годится - посредственно плохо.
Причем оно актуально в основном для супермодных процессоров. Ну эти...облачкааа... могут себе позволить раз в пол-года обновлять свои картонные серверы. Те ж все равно на долгую счастливую жизнь не рассчитаны.
Это ж у корпов оно живет по десятку лет.
> В такой ситуации там должен быть жесткий cache hit
а его нету. Потому что глобальная переменная. И лежит очень далеко от того что обрабатывается прямо сейчас.
Плюс те самые анти-оптимизации намеренно инвалидирующие все кэширование к чертям.
Т.е. я тебе вполне верю что (опять на суперсовременном со всеми новыми бесполезными командами) процессоре off от auto отличается на единицы процентов.
Просто тестировать надо было не это.
