Как я производительность в игрушках выжимал

Всё началось с того, что я решил переехать с Windows на Linux в качестве платформы для игр.
Просто было интересно пощупать, так сказать.

После запуска системы, я смотрел в dmesg и разбирал присутствующие ошибки. Сначала поборол UEFI с поддержкой Secure Boot + свой MOK, boot-опции для графики типа nvidia_drm.modeset=1 и прочие, но одно предупреждение я проигнорировал:

TSC synchronization [CPU#0 -> CPU#2]:
Measured 6302355364 cycles TSC warp between CPUs, turning off TSC clock.
tsc: Marking TSC unstable due to check_tsc_sync_source failed
clocksource: Switched to clocksource hpet

Разумеется, я гуглил на эту тему, и даже чатжипитировал, но всё сводилось к тому, что это типа ничего страшного, так бывает; просто ядро ОС не синхронизировало таймеры между ядрами процессора. Да и мне всё это казалось логично, что на многоядерной системе, всё крутиться начинает с первого ядра, а потом включаются в работу и остальные, что собственно и вызывает задержку (6.3 миллиарда тактов при частоте ~3ГГц - это примерно 2 секунды). В итоге, ядро Linux пометило TSC как ненадёжный и перешло к таймеру HPET. Ну ОК, подумал я, HPET, так HPET, тем более я помню этот таймер ещё со школьных времён (из настроек BIOS), но я пока не знал, что он будет медленнее модного и современного TSC. А узнал я это, когда начал запускать игрушки в Linux: вроде-бы всё работает, но как-то всё равно не то, нет плавности ввода и вывода, видно, как кадр хочет отрендериться, но что-то мешает, не комфортно...

Опять начал гуглить и яндексировать на тему повышения производительности игр в среде Linux, и дошёл до оптимизаций ядра, где надо собрать своё кастомное ядро, или попробовать сборки Zen и тому подобные, kernel boot params. Перепробовал многое... В итоге, я нашёл один boot-параметр, который реально помог! Это был tsc=reliable, и действительно, даже работа самой ОС стала плавнее и отзывчивее, а в игрушках появилась та самая плавность, как в Windows.

По-идее, таймер, процессор - всё это низкий уровень, а ядро должно быть умным уметь заботится о синхронизации из коробки. Моя мысля подтвердилась, когда залез в исходники. Обнаружил, что tsc_sync.c делает синхронизацию, но не для тех платформ, которые не умеют в TSC_ADJUST (например, как мой процессор AMD Ryzen).

Таким образом, я решил создать свой патч для калибровки TSC. Сразу возникла идея: cpu0 - эталон, берём его в качестве эталона и копируем его значение таймера в остальные процессоры/ядра. Получилось, но со второго раза, когда количество попыток синхронизации увеличил с 3 до 16 в функции check_tsc_sync_source. В dmesg виднеется, что clocksource теперь живёт на tsc, а не на медленном hpet. Казалось бы, ура, проблема решена, ан нет, хоть tsc и активен, но ощущения присутствия hpet остались. То есть, вроде бы всё норм, но плавности ввода в играх не было, как это было при tsc=reliable.

Тут я сдался и ушёл в чатгпт за советами и исследованиями. Он меня похвалил)) и подсказал, что это известная проблема и её уже решали, например, вот тут https://github.com/CachyOS/linux-cachyos/issues/925 (просто иногда я гуглить не умею).
Почитав чужой код, я пропросил ИИ добавить логику перемотки таймера вперёд для 1-го ядра, а не назад, как это я сделал изначально для остальных ядер. И вот тут действительное Ура!

ИИшка вписала логику, вынесла активатор патча в отдельную boot-опцию tsc_fixwarp

В общем, я доволен проделанной работой и результатом, и плавностью игр под Linux.

Вот патч https://github.com/johnaka1337/debian-he/blob/main/kernel_patches/001-tsc_sync.patch вдруг кому-то пригодится.

Для меня дилемма: это должно решаться стороною ОС, или всё-таки прошивкой? Чатгпт говорит, что это кривой биос, а вот тут https://forums.lenovo.com/t5/Ubuntu/Legion-5-15ACH6H-82JU-BSP-TSC-not-synchronized-with-other-cores-after-POST/m-p/10046313 уже запросили фикс. А вот тут https://stackoverflow.com/a/10492098 говорят, что это basically на стороне ОС... Я не знаю, кто прав, а кто нет, но с патчем стало жить гораздо плавнее)