Какие изменения происходят при установке параметра tsc=unstable в конфигурации ядра?

У меня есть bare-metal сервер с ядром 5.15.82 и оборудованием Supermicro X9DRD-iF/LF/X9DRD-iF, на котором установлены два 12-головых процессора. После установки я начал получать такие сообщения: 
<blockquote>
Sep 11 19:51:18 nakivo kernel: clocksource: timekeeping watchdog on CPU22: hpet wd-wd read-back delay of 141219ns  
Sep 11 19:51:18 nakivo kernel: clocksource: wd-tsc-wd read-back delay of 156723ns, clock-skew test skipped!
</blockquote> 
Эти сообщения появляются регулярно. Я нашел информацию в интернете, например, <a href="https://bbs.archlinux.org/viewtopic.php?id=278494" rel="nofollow">в этом треде</a>, но не совсем понял обсуждаемое. Я попытался настроить предложенные параметры; установка <b>clocksource=hpet</b> не помогла, а <b>tsc=unstable</b> устранила сообщения. Возникновение следующего сообщения в логе меня удивило: 
<blockquote>
Sep 16 19:59:41 nakivo kernel: tsc: Marking TSC unstable due to boot parameter
</blockquote> 

Использовалась также рекомендация по установке параметра <b>tsc=nowatchdog</b> и конфигурационного параметра ядра CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US. В другом источнике ( <a href="https://patchew.org/linux/20230125002708.GA1471122@paulmck-ThinkPad-P17-Gen-1/[email protected]/" rel="nofollow">здесь</a> ) упоминается установка его в 125 мкс. 

В связи с этим у меня есть несколько вопросов: 
1. На что влияет параметр tsc?
2. Какие последствия установки tsc в unstable и nowatchdog?
3. Как это связано с CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US?
4. Какое решение является более предпочтительным: установка параметра tsc или изменение конфигурационного параметра?
  • 16 сентября 2024 г. 18:13
Ответы на вопрос 2
Параметр `tsc` (Time Stamp Counter) в конфигурации ядра Linux влияет на использование тактового счетчика процессора, который может быть важным для системного времени и синхронизации. Я постараюсь ответить на ваши вопросы, основываясь на вашем случае с ядром 5.15.82 и сервером на архитектуре x86 с двумя процессорами.

### 1. На что влияет параметр tsc?
Параметр `tsc` управляет тем, как ядро будет взаимодействовать с TSC:
- `tsc=unstable`: Указывает ядру, что TSC может быть ненадёжным (например, если он не синхронизирован между ядрами). В этом случае ядро не будет использовать TSC в качестве основного временного источника.
- `tsc=nowatchdog`: Отключает функцию watchdog для TSC, что предотвратит появление сообщений о задержках, если TSC не стабильный. Это может быть полезно, если вы знаете, что ваш TSC имеет проблемы, но не хотите получать постоянные уведомления.

### 2. Какие последствия установки tsc в unstable и nowatchdog?
- **`tsc=unstable`**: Если установлен, то ядро не будет использовать TSC в качестве временного источника, что может привести к снижению производительности в задачах, требующих высокой точности времени, так как оно может перейти к менее точным источникам, таким как HPET или ACPI PM Timer.
- **`tsc=nowatchdog`**: Это предотвращает сообщения о сбоях TSC, но не решает проблему с ненадёжностью TSC. Это может привести к тому, что система будет работать без уведомлений о смещениях времени, что не всегда хорошо, если TSC действительно нестабилен.

### 3. Как это связано с CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US?
Опция `CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US` устанавливает максимальное смещение (в микросекундах) между временными источниками, которое ядро будет терпеть, прежде чем оно решит, что временной источник ненадёжен и активирует функции watchdog. Если TSC отклоняется более чем на установленные значения, это может вызвать активацию watchdog, что приводит к сообщениям о сбоях TSC. Установка значения, например, 125 мкс, может позволить системе работать стабильнее, если фактическое смещение времени не превышает это значение.

### 4. Какое решение является более предпочтительным: установка параметра tsc или изменение конфигурационного параметра?
- Если вы уверены, что TSC действительно нестабилен и вы не нуждаетесь в высокой точности временных меток, установка `tsc=unstable` может быть разумным решением. Однако это можетж привести к снижению производительности при определенных условиях.
- Если у вас есть возможность изменить конфигурацию ядра, то регулировка `CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US` может быть более подходящим решением, позволяющим оптимизировать работу системы, сохраняя при этом возможность использования TSC.

На практике, подходящий вариант часто зависит от специфики вашей системы и работы, которую она выполняет. Вы можете начать с `tsc=unstable` и следить за производительностью вашего приложения, и если потребуется - попробовать уточнить настройки watchdog.
на что влияет параметр tsc

Если включить tsc=unstable:
- Игнорируется TSC как источник времени, если он обнаружен как нестабильный.
- Переключение на альтернативные таймеры, которые могут быть более стабильными, но немного медленнее в работе, например HPET или ACPI PMTIMER.

Насколько я вычитал из гугла, это не баг, а следствие кучи технологий сохранения энергии типа динамической частоты, снижения энерго потребления. Процессору, а особенно двум тяжело синхронизировать время и они переходят на другой способ синхронизации HPET, что в свою очередь незначительно понижает производительность. Кстати HPET надо включить в bios (High Precision Event Timer).

В большинстве задач использование HPET снизит продуктивность процессора на 1-3%, для виртуализации это может быть около 10%. Все зависит от систем которые будут использоваться, насколько эти системы критичны к времени, например база данных.

Можно попробовать поиграться с настройками BIOS выключив настройки энегро экономии, разные acpi sleep state, dynamic frequency, C-states або SpeedStep

Возможно есть свежий bios в котором пофиксили проблему. Более свежее ядро linux так же может помоч.
Похожие вопросы