Поддержка счётчика временных меток Time Stamp Counter (TSC) впервые стала обязательным требованием для процессоров x86 в Linux. Это произошло более чем через десять лет после того, как Microsoft начала использовать TSC в качестве основного средства высокоточного измерения времени в Windows.
Изменение удаляет из ядра оставшиеся параметры конфигурации, которые позволяли собрать версию для архитектуры x86 без поддержки TSC. Коммит «x86/cpu: Make CONFIG_X86_TSC unconditional» авторства Инго Молнара, сопровождающего архитектуру x86, делает эту функцию безусловной: предполагается, что все поддерживаемые сейчас процессоры x86 уже оснащены TSC.
На первый взгляд это выглядит как незначительная очистка кода ядра. Однако фактически изменение завершает целую эпоху поддержки в Linux чрезвычайно старого оборудования на базе архитектуры x86.
Изменение вошло в состав ядра Linux 7.2, выпущенного 16 августа 2026 года. Параметр CONFIG_X86_TSC в файле arch/x86/Kconfig.cpu теперь объявлен как def_bool y без каких-либо условий. Сам код для систем без TSC будет удалён отдельным набором изменений.
Что такое TSC
TSC представляет собой специальный 64-битный регистр процессора, который работает как счётчик тактов с момента последнего сброса. Данная технология появилась ещё во времена процессоров Intel Pentium.
- Позволяет измерять прошедшее время с высокой точностью и обеспечивает очень детализированные временные показатели.
- Доступ к TSC выполняется значительно быстрее, чем к платформенным таймерам вроде HPET (High Precision Event Timer) или таймера управления питанием ACPI PM, поскольку TSC является регистром непосредственно внутри процессора.
- Считывается инструкциями RDTSC и RDTSCP.
Производительность всегда была одним из ключевых показателей развития программного и аппаратного обеспечения, поэтому приоритет TSC вполне закономерен. Сегодня каждый современный процессор Intel и AMD оснащён 64-битным счётчиком TSC.
Почему код для систем без TSC держали так долго
Linux исторически приходилось сохранять код для процессоров, которые либо не имели TSC, либо не могли надёжно его использовать. Причина в том, что ядро долгое время поддерживало оборудование, выпущенное ещё в эпоху i486. Для таких систем требовались прослойки, эмулирующие TSC и инструкцию CX8 (CMPXCHG8B), а также библиотека math-emu для эмуляции математического сопроцессора.
Отказ шёл в два этапа:
- Ядро Linux 7.0, вышедшее 12 апреля 2026 года, ещё позволяло собрать систему для i486.
- В Linux 7.1 от 14 июня 2026 года из Kconfig убрали параметры
CONFIG_M486,CONFIG_M486SXиCONFIG_MELAN, то есть собрать ядро для процессоров класса 486 стало невозможно. - В Linux 7.2 удалили параметр
CONFIG_M586для процессоров i586 без TSC, под который попали AMD K5 и ряд моделей Cyrix, а такжеCONFIG_MWINCHIP3Dи код эмуляции сопроцессораCONFIG_MATH_EMULATION.
После этого ядро может исходить из того, что любой поддерживаемый процессор x86 оснащён TSC. Поддержку процессоров i386 из ядра убрали ещё в 2012 году.
Данное изменение не означает, что Linux внезапно стала зависеть от функции, которой нет на современных компьютерах. Разработчики лишь удалили код совместимости, который на протяжении десятилетий был необходим для поддержки устаревших процессоров. Похожая работа идёт и по другим направлениям: например, из ядра удаляют код российских процессоров Baikal из-за отсутствия сопровождения.
Как к TSC пришла Microsoft
Интересно, что Microsoft приняла похожий подход гораздо раньше, хотя в случае с Windows ситуация заметно отличается. Высокоточный счётчик производительности QueryPerformanceCounter (QPC) появился в Windows 2000 и Windows XP.
- Windows 2000 и Windows XP. QPC работал на большинстве систем, однако BIOS части компьютеров неверно сообщал характеристики процессора, а на многоядерных и многопроцессорных машинах счётчики отдельных ядер не удавалось синхронизировать. На таком оборудовании показания QPC на разных ядрах могли расходиться.
- Windows Vista и Windows Server 2008. Все компьютеры, поставлявшиеся с этими системами, использовали в качестве основы QPC платформенный счётчик HPET или таймер управления питанием ACPI PM. Такие таймеры общие для всех процессоров и имеют большую задержку доступа, что ограничивает масштабируемость при одновременных обращениях.
- Windows 7 и Windows Server 2008 R2. Большинство машин получили процессоры с TSC постоянной частоты, и именно они стали основой QPC на системах с одним тактовым доменом, где операционная система или гипервизор может синхронизировать счётчики всех процессоров при инициализации.
- Windows 8, Windows 8.1, Windows Server 2012 и 2012 R2. TSC стал основой счётчика производительности, а алгоритм синхронизации был существенно улучшен для крупных систем с большим числом процессоров. Тогда же появился программный интерфейс GetSystemTimePreciseAsFileTime для получения точных значений астрономического времени.
При этом Windows по-прежнему проверяет при инициализации, пригоден ли TSC для отсчёта времени. Если счётчик не соответствует требованиям, система автоматически выбирает другой аппаратный таймер – HPET или ACPI PM. Компания также настоятельно не рекомендует разработчикам считывать TSC напрямую инструкциями RDTSC и RDTSCP: результат окажется ненадёжным на части версий Windows, при переносе работающих виртуальных машин и на оборудовании без инвариантного или синхронизированного TSC. Вместо этого предлагается использовать QPC.
Разница в скорости
Microsoft отдаёт предпочтение TSC неслучайно. По данным компании, чтение QPC на основе TSC занимает от нескольких десятков до нескольких сотен процессорных тактов в зависимости от модели процессора. Если TSC использовать нельзя, система переключается на таймер, расположенный на материнской плате, и стоимость одного вызова вырастает примерно до 0,8–1,0 микросекунды. Основное время при этом уходит на обращение к устройству на плате.
Кроме того, QPC на основе TSC не требует перехода в режим ядра. Избежать системного вызова невозможно, если Windows приходится использовать альтернативные таймеры, включая HPET или ACPI PM.
Разработчикам Linux на протяжении многих лет приходилось выявлять проблемы с надёжностью TSC, калибровать счётчик и применять различные обходные решения. Теперь один из старейших фрагментов этого кода совместимости наконец удаляют. Ознакомиться с изменением можно в репозитории ядра Linux.