Потерянные циклы на Intel? Несоответствие между rdtsc и CPU_CLK_UNHALTED.REF_TSC
На последних процессорах (по крайней мере, в последнее десятилетие или около того) Intel предложила три аппаратных счетчика производительности с фиксированной функцией в дополнение к различным настраиваемым счетчикам производительности. Три фиксированных счетчика:
INST_RETIRED.ANY
CPU_CLK_UNHALTED.THREAD
CPU_CLK_UNHALTED.REF_TSC
Первый подсчитывает удаленные инструкции, второй - число реальных циклов, а последний - то, что нас интересует. Описание для Тома 3 руководства Intel для разработчиков программного обеспечения:
Это событие подсчитывает количество опорных циклов на скорости TSC, когда ядро не находится в состоянии остановки и не находится в состоянии остановки ТМ. Ядро переходит в состояние остановки, когда выполняется инструкция HLT или инструкция MWAIT. На это событие не влияют изменения частоты ядра (например, состояния P), но он учитывается на той же частоте, что и счетчик меток времени. Это событие может приблизительно соответствовать истекшему времени, пока ядро не находилось в состоянии остановки и не находилось в состоянии таймера ТМ.
Так что для цикла с привязкой к ЦП я ожидаю, что это значение будет таким же, как и значение свободного TSC, считываемое rdstc, поскольку они должны расходиться только для команд с остановленными циклами или для определения состояния останова ТМ.
Я проверяю это с помощью следующего цикла (вся автономная демонстрация доступна на github):
for (int i = 0; i < 100; i++) {
PFC_CNT cnt[7] = {};
int64_t start = nanos();
PFCSTART(cnt);
int64_t tsc =__rdtsc();
busy_loop(CALIBRATION_LOOPS);
PFCEND(cnt);
int64_t tsc_delta = __rdtsc() - tsc;
int64_t nanos_delta = nanos() - start;
printf(CPU_W "d" REF_W ".2f" TSC_W ".2f" MHZ_W ".2f" RAT_W ".6f\n",
sched_getcpu(),
1000.0 * cnt[PFC_FIXEDCNT_CPU_CLK_REF_TSC] / nanos_delta,
1000.0 * tsc_delta / nanos_delta,
1000.0 * CALIBRATION_LOOPS / nanos_delta,
1.0 * cnt[PFC_FIXEDCNT_CPU_CLK_REF_TSC]/tsc_delta);
}
Единственная важная вещь в области времени busy_loop(CALIBRATION_LOOPS); это просто тесная петля изменчивых магазинов, которые, как составлено gcc а также clang выполняется за один цикл на одну итерацию на последнем оборудовании:
void busy_loop(uint64_t iters) {
volatile int sink;
do {
sink = 0;
} while (--iters > 0);
(void)sink;
}
PFCSTART а также PFCEND Команды читают CPU_CLK_UNHALTED.REF_TSC счетчик с использованием libpfc. __rdtsc() является внутренним, который читает TSC через rdtsc инструкция. Наконец, мы измеряем в реальном времени nanos() что просто:
int64_t nanos() {
auto t = std::chrono::high_resolution_clock::now();
return std::chrono::time_point_cast<std::chrono::nanoseconds>(t).time_since_epoch().count();
}
Да я не выдаю cpuid и вещи не чередуются точно, но цикл калибровки занимает целую секунду, поэтому такие проблемы наносекундного масштаба просто уменьшаются до более или менее ничего.
С включенным TurboBoost вот несколько первых результатов типичной работы моего процессора i7-6700HQ Skylake:
CPU# REF_TSC rdtsc Eff Mhz Ratio
0 2392.05 2591.76 2981.30 0.922946
0 2381.74 2591.79 3032.86 0.918955
0 2399.12 2591.79 3032.50 0.925660
0 2385.04 2591.79 3010.58 0.920230
0 2378.39 2591.79 3010.21 0.917663
0 2355.84 2591.77 2928.96 0.908970
0 2364.99 2591.79 2942.32 0.912492
0 2339.64 2591.77 2935.36 0.902720
0 2366.43 2591.79 3022.08 0.913049
0 2401.93 2591.79 3023.52 0.926747
0 2452.87 2591.78 3070.91 0.946400
0 2350.06 2591.79 2961.93 0.906733
0 2340.44 2591.79 2897.58 0.903020
0 2403.22 2591.79 2944.77 0.927246
0 2394.10 2591.79 3059.58 0.923723
0 2359.69 2591.78 2957.79 0.910449
0 2353.33 2591.79 2916.39 0.907992
0 2339.58 2591.79 2951.62 0.902690
0 2395.82 2591.79 3017.59 0.924389
0 2353.47 2591.79 2937.82 0.908047
Вот, REF_TSC является фиксированным счетчиком производительности TSC, как описано выше, и rdtsc является результатом от rdtsc инструкция. Eff Mhz является эффективной рассчитанной истинной частотой процессора за интервал и в основном показана для любопытства и в качестве быстрого подтверждения того, сколько турбо срабатывает. Ratio это отношение REF_TSC а также rdtsc колонны. Я ожидал бы, что это будет очень близко к 1, но на практике мы видим, что оно колеблется от 0,90 до 0,92 с большой разницей (я видел, что оно было всего лишь 0,8 на других трассах).
Графически это выглядит примерно так 2:
rdstc Вызов возвращает почти точные результаты 1, в то время как счетчик TSC PMU повсюду, иногда почти до 2300 МГц.
Однако, если я отключу турбо, результаты будут гораздо более последовательными:
CPU# REF_TSC rdtsc Eff Mhz Ratio
0 2592.26 2592.25 2588.30 1.000000
0 2592.26 2592.26 2591.11 1.000000
0 2592.26 2592.26 2590.40 1.000000
0 2592.25 2592.25 2590.43 1.000000
0 2592.26 2592.26 2590.75 1.000000
0 2592.26 2592.26 2590.05 1.000000
0 2592.25 2592.25 2590.04 1.000000
0 2592.24 2592.24 2590.86 1.000000
0 2592.25 2592.25 2590.35 1.000000
0 2592.25 2592.25 2591.32 1.000000
0 2592.25 2592.25 2590.63 1.000000
0 2592.25 2592.25 2590.87 1.000000
0 2592.25 2592.25 2590.77 1.000000
0 2592.25 2592.25 2590.64 1.000000
0 2592.24 2592.24 2590.30 1.000000
0 2592.23 2592.23 2589.64 1.000000
0 2592.23 2592.23 2590.83 1.000000
0 2592.23 2592.23 2590.49 1.000000
0 2592.23 2592.23 2590.78 1.000000
0 2592.23 2592.23 2590.84 1.000000
0 2592.22 2592.22 2588.80 1.000000
В основном, это соотношение составляет 1,000000 до 6 знаков после запятой.
Графически (с масштабом оси Y, который должен быть таким же, как предыдущий график):
Теперь код просто выполняет горячий цикл, и там не должно быть hlt или же mwait инструкции, конечно, ничего, что подразумевало бы отклонение более чем на 10%. Я не могу с уверенностью сказать, что такое "циклы секундомера ТМ", но могу поспорить, что это "циклы секунд терморегулирования", трюк, используемый для временного регулирования ЦП, когда он достигает максимальной температуры. Тем не менее, я посмотрел показания встроенного термистора и никогда не видел перерыва ЦП 60C, намного ниже 90C-100C, где начинается термическое управление (я думаю).
Есть идеи, что это может быть? Есть ли подразумеваемые "циклы остановки" для перехода между разными турбо частотами? Это определенно происходит, потому что коробка не тихая, и поэтому турбо-частота скачет вверх и вниз, так как другие ядра запускаются и перестают работать на фоновом режиме (максимальная турбо-частота напрямую зависит от количества активных ядер: на моем боксе это 3,5, 3.3, 3.2, 3.1 ГГц для 1, 2, 3 или 4 активных ядер соответственно).
На самом деле, какое-то время я действительно получал точные результаты с точностью до двух знаков после запятой: 2591.97 MHz - итерация за итерацией. Затем что-то изменилось, и я не совсем уверен, что и есть небольшое отклонение около 0,1% в rdstc Результаты. Одной из возможностей является постепенная настройка часов, выполняемая подсистемой синхронизации Linux, чтобы привести местное время кристалла в соответствие с ntpd определенное время Возможно, это просто дрейф кристаллов - последний график, приведенный выше, показывает устойчивое увеличение измеренного периода rdtsc каждую секунду.
2 Графики не соответствуют тем же прогонам, что и значения, показанные в тексте, потому что я не собираюсь обновлять графики каждый раз, когда меняю формат вывода текста. Однако качественное поведение практически одинаково при каждом запуске.
1 ответ
TL;DR
Несоответствие, которое вы наблюдаете между RDTSC а также REFTSC и происходит из-за переходов P-состояний TurboBoost. Во время этих переходов большая часть ядра, включая счетчик производительности с фиксированной функцией REF_TSC, останавливается примерно на 20000-21000 циклов (8.5us), но rdtsc продолжается на своей инвариантной частоте. rdtsc вероятно, находится в изолированной области питания и синхронизации, потому что это так важно и из-за задокументированного поведения, похожего на настенные часы.
RDTSC-REFTSC несовпадение
Несоответствие проявляется как тенденция к RDTSC пересчет REFTSC, Чем дольше работает программа, тем больше положительной разницы RDTSC-REFTSC как правило. На очень длинных отрезках он может достигать 1%-2% или даже выше.
Конечно, вы уже заметили, что при отключении TurboBoost перерасчет исчезает, что можно сделать следующим образом при использовании intel_pstate:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
Но это не говорит нам наверняка, что TurboBoost виноват в несоответствии; Может случиться так, что более высокие P-состояния, включенные TurboBoost, пожирают доступный запас, вызывая тепловое удушение и остановки.
Возможно Дросселирование?
TurboBoost - это решение для динамического масштабирования частоты и напряжения, позволяющее оптимально использовать запас по размеру рабочей зоны (тепловой или электрический). По возможности TurboBoost будет увеличивать частоту ядра и напряжение процессора до их номинального значения, улучшая производительность за счет более высокого энергопотребления.
Конечно, более высокая потребляемая мощность увеличивает температуру ядра и энергопотребление. В конце концов, будет достигнут некоторый предел, и TurboBoost придется снизить производительность.
TM1 Термическое дросселирование?
Я начал с исследования того, вызывает ли термическое регулирование схема (TCC) для Thermal Monitor 1 (TM1) или 2 (TM2). TM1 снижает энергопотребление, вставляя тактовые такты TM, и это одно из задокументированных условий, приводящее к остановке REFTSC, ТМ2, с другой стороны, не управляет часами; Это только масштабирует частоту.
Я модифицировал libpfc() чтобы я мог читать выбранные MSR, в частности IA32_PACKAGE_THERM_STATUS а также IA32_THERM_STATUS СПП. Оба содержат состояние "только для чтения" и аппаратно-зависимый флаг журнала "чтение-запись" для различных температурных условий:
(The
IA32_PACKAGE_THERM_STATUSрегистр практически одинаковый)
Хотя некоторые из этих битов иногда устанавливались (особенно при блокировке вентиляционных отверстий ноутбука!), Они, похоже, не коррелировали с RDTSC избыточный пересчет, который будет надежно происходить независимо от теплового состояния.
Hardware Duty Cycling? C-State Residency?
Копаясь в другом месте в SDM для оборудования, похожего на часы, я столкнулся с HDC (Hardware Duty Cycle), механизмом, с помощью которого ОС может вручную запрашивать процессор для работы только в фиксированной пропорции времени; Аппаратное обеспечение HDC реализует это путем запуска процессора в течение 1–15 тактов в течение 16-часового периода и принудительного холостого хода в течение оставшихся 15–1 тактов этого периода.
HDC предлагает очень полезные регистры, в частности MSR:
IA32_THREAD_STALL: Подсчитывает количество остановленных циклов из-за принудительного холостого хода на этом логическом процессоре.MSR_CORE_HDC_RESIDENCY: То же, что и выше, но для физического процессора, подсчитывает циклы, когда один или несколько логических процессоров этого ядра работают на холостом ходу.MSR_PKG_HDC_SHALLOW_RESIDENCY: Подсчитывает циклы, в течение которых пакет находился в состоянии C2, и по крайней мере один логический процессор находился в режиме ожидания.MSR_PKG_HDC_DEEP_RESIDENCY: Подсчитывает циклы, в течение которых пакет находился в более глубоком (точно настраиваемом) C-состоянии, и по крайней мере один логический процессор находился в режиме принудительного простоя
Для получения более подробной информации см. Intel SDM Volume 3, глава 14, § 14.5.1 Интерфейс программирования аппаратного режима работы.
Но мой процессор i7-4700MQ 2,4 ГГц не поддерживает HDC, и так было и с HDC.
Другие источники удушения?
Еще немного покопавшись в Intel SDM, я обнаружил очень, очень сочную MSR: MSR_CORE_PERF_LIMIT_REASONS, Этот регистр сообщает большое количество очень полезных битов статуса и липкого журнала:
690H MSR_CORE_PERF_LIMIT_REASONS - Пакет - Индикатор ограничения частоты в ядрах процессора
- Немного
0: ПРОЧОТ Статус- Немного
1: Тепловой статус- Немного
4: Состояние графического драйвера. Если установлено, частота уменьшается ниже запроса операционной системы из-за переопределения драйвера графического процессора.- Немного
5: Состояние управления частотой на основе автономного использования. Когда установлено, частота уменьшается ниже запроса операционной системы, потому что процессор обнаружил, что загрузка низкая.- Немного
6: Тепловой сигнал регулятора напряжения. Когда установлено, частота уменьшается ниже запроса операционной системы из-за теплового предупреждения от регулятора напряжения.- Немного
8: Точка электрического проектирования. Когда установлено, частота уменьшается ниже запроса операционной системы из-за ограничений расчетной электрической точки (например, максимальное потребление электрического тока).- Немного
9: Состояние ограничения мощности ядра. Когда установлено, частота уменьшается ниже запроса операционной системы из-за ограничения мощности на уровне домена.- Немного
10: Ограничение мощности на уровне пакета Состояние PL1. Когда установлено, частота снижается ниже запроса операционной системы из-за ограничения мощности PL1 на уровне пакета.- Немного
11: Ограничение мощности на уровне пакета Состояние PL2. Когда установлено, частота уменьшается ниже запроса операционной системы из-за ограничения мощности PL2 на уровне пакета.- Немного
12: Макс. Турбо Лимит Статус. Когда установлено, частота снижается ниже запроса операционной системы из-за многоядерных турбо-ограничений.- Немного
13: Состояние ослабления при турбо-переходе. Когда установлено, частота уменьшается ниже запроса операционной системы из-за затухания турбо перехода. Это предотвращает снижение производительности из-за частых изменений коэффициента использования.- Немного
16: ПРОЧОТ Лог- Немного
17: Тепловой журнал- Немного
20: Графический драйвер- Немного
21: Журнал контроля частоты на основе автономного использования- Немного
22: Регулятор напряжения Thermal Alert Log- Немного
24: Журнал проектирования электрооборудования- Немного
25: Журнал ограничения мощности ядра- Немного
26: Ограничение мощности на уровне пакета PL1 Log- Немного
27: Ограничение мощности на уровне пакета PL2 Log- Немного
28: Макс Турбо Лимит Лог- Немного
29: Журнал Турбо Перехода Затухания
pfc.ko теперь поддерживает этот MSR, и демонстрационная версия печатает, какой из этих битов журнала активен. pfc.ko Драйвер очищает липкие биты при каждом чтении.
Я перезапускаю ваши эксперименты во время печати битов, и мой ЦП сообщает при очень большой нагрузке (все 4 ядра /8 потоков активны) о нескольких ограничивающих факторах, включая точку электрического проектирования и ограничение мощности ядра. Биты уровня пакета PL2 и Max Turbo Limit всегда устанавливаются на моем процессоре по неизвестным мне причинам. Я также видел иногда Turbo Transition Attenuation.
Хотя ни один из этих битов точно не связан с наличием RDTSC-REFTSC Несоответствие, последний бит дал мне пищу для размышлений. Простое существование турбопереходного ослабления подразумевает, что переключение P-состояний имеет достаточно существенную стоимость, что оно должно быть ограничено по скорости с некоторым механизмом гистерезиса. Когда я не смог найти MSR, который посчитал эти переходы, я решил сделать следующую лучшую вещь - я буду использовать величину RDTSC-REFTSC Пересчет, чтобы охарактеризовать влияние на производительность перехода TurboBoost.
эксперимент
Установка эксперимента заключается в следующем. На моем процессоре i7-4700MQ с номинальной частотой 2,4 ГГц и максимальной турбо-скоростью 3,4 ГГц я отключу все ядра, кроме 0 (загрузочный процессор) и 3 (удобное ядро-жертва, не имеющее нуля и не являющееся логическим родителем 0). Затем мы спросим intel_pstate драйвер, чтобы дать нам производительность пакета не менее 98% и не выше 100%; Это заставляет процессор колебаться между вторым самым высоким и самым высоким P-состояниями (3,3 ГГц и 3,4 ГГц). Я делаю это следующим образом:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu4/online
echo 0 > /sys/devices/system/cpu/cpu5/online
echo 0 > /sys/devices/system/cpu/cpu6/online
echo 0 > /sys/devices/system/cpu/cpu7/online
echo 98 > /sys/devices/system/cpu/intel_pstate/min_perf_pct
echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
Я запустил демонстрационное приложение для 10000 образцов в
1000, 1500, 2500, 4000, 6300,
10000, 15000, 25000, 40000, 63000,
100000, 150000, 250000, 400000, 630000,
1000000, 1500000, 2500000, 4000000, 6300000,
10000000, 15000000, 25000000, 40000000, 63000000
наносекунды в add_calibration() выполняется с номинальной частотой процессора (умножьте числа выше на 2,4, чтобы получить фактический аргумент add_calibration()).
Результаты
Это производит журналы, которые выглядят следующим образом (случай 250000 нано):
CPU 0, measured CLK_REF_TSC MHz : 2392.56
CPU 0, measured rdtsc MHz : 2392.46
CPU 0, measured add MHz : 3286.30
CPU 0, measured XREF_CLK time (s) : 0.00018200
CPU 0, measured delta time (s) : 0.00018258
CPU 0, measured tsc_delta time (s) : 0.00018200
CPU 0, ratio ref_tsc :ref_xclk : 24.00131868
CPU 0, ratio ref_core:ref_xclk : 33.00071429
CPU 0, ratio rdtsc :ref_xclk : 24.00032967
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : -18
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018001000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz : 2392.63
CPU 0, measured rdtsc MHz : 2392.62
CPU 0, measured add MHz : 3288.03
CPU 0, measured XREF_CLK time (s) : 0.00018192
CPU 0, measured delta time (s) : 0.00018248
CPU 0, measured tsc_delta time (s) : 0.00018192
CPU 0, ratio ref_tsc :ref_xclk : 24.00000000
CPU 0, ratio ref_core:ref_xclk : 32.99983509
CPU 0, ratio rdtsc :ref_xclk : 23.99989006
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : -2
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018001000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz : 2284.69
CPU 0, measured rdtsc MHz : 2392.63
CPU 0, measured add MHz : 3151.99
CPU 0, measured XREF_CLK time (s) : 0.00018121
CPU 0, measured delta time (s) : 0.00019036
CPU 0, measured tsc_delta time (s) : 0.00018977
CPU 0, ratio ref_tsc :ref_xclk : 24.00000000
CPU 0, ratio ref_core:ref_xclk : 33.38540919
CPU 0, ratio rdtsc :ref_xclk : 25.13393301
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : 20548
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018000000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz : 2392.46
CPU 0, measured rdtsc MHz : 2392.45
CPU 0, measured add MHz : 3287.80
CPU 0, measured XREF_CLK time (s) : 0.00018192
CPU 0, measured delta time (s) : 0.00018249
CPU 0, measured tsc_delta time (s) : 0.00018192
CPU 0, ratio ref_tsc :ref_xclk : 24.00000000
CPU 0, ratio ref_core:ref_xclk : 32.99978012
CPU 0, ratio rdtsc :ref_xclk : 23.99989006
CPU 0, core CLK cycles in OS : 0
CPU 0, User-OS transitions : 0
CPU 0, rdtsc-reftsc overcount : -2
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS : 0000000018001000
PROCHOT
Thermal
Graphics Driver
Autonomous Utilization-Based Frequency Control
Voltage Regulator Thermal Alert
Electrical Design Point (e.g. Current)
Core Power Limiting
Package-Level PL1 Power Limiting
* Package-Level PL2 Power Limiting
* Max Turbo Limit (Multi-Core Turbo)
Turbo Transition Attenuation
Я сделал несколько замечаний по поводу бревен, но одно выделилось:
Для nanos <~ 250000 перерасчет RDTSC незначителен. Для nanos > ~250000 можно надежно наблюдать превышение тактовых тактов чуть более 20000 тактовых циклов. Но они не из-за переходов между пользователем и ОС.
Вот визуальный сюжет:
Насыщенные синие точки: 0 стандартных отклонений (близко к среднему)
Насыщенные красные точки: +3 стандартных отклонения (выше среднего)
Насыщенные зеленые точки: -3 стандартных отклонения (ниже среднего)
Существует заметная разница до, во время и после примерно 250000 наносекунд устойчивого снижения.
Нанос < 250000
До порогового значения журналы CSV выглядят так:
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,-4,3639,1
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-44,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,12,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,32,3171,1
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
Показав, что соотношение TurboBoost идеально стабильно при 33х, RDTSC это считается синхронно с REFTSC в 24 раза REF_XCLK (100 МГц), незначительное превышение, обычно 0 циклов, проведенных в ядре и, таким образом, 0 переходов в ядро. Прерывания ядра занимают около 3000 опорных циклов для обслуживания.
Нанос == 250000
При критическом пороговом значении журнал содержит скопления 20000 циклов перерасчета, и перерасчета очень хорошо коррелируют с нецелыми оценочными значениями множителя между 33x и 34x:
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,2,0,0
24.00,33.00,24.00,22,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.05,25.11,20396,0,0
24.00,33.38,25.12,20212,0,0
24.00,33.39,25.12,20308,0,0
24.00,33.42,25.12,20296,0,0
24.00,33.43,25.11,20158,0,0
24.00,33.43,25.11,20178,0,0
24.00,33.00,24.00,-4,0,0
24.00,33.00,24.00,20,3920,1
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-4,0,0
24.00,33.44,25.13,20396,0,0
24.00,33.46,25.11,20156,0,0
24.00,33.46,25.12,20268,0,0
24.00,33.41,25.12,20322,0,0
24.00,33.40,25.11,20216,0,0
24.00,33.46,25.12,20168,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,22,0,0
Нанос> 250000
TurboBoost с 3,3 ГГц до 3,4 ГГц теперь работает надежно. По мере увеличения наноса, журналы заполняются примерно целым числом, кратным 20000 циклам. В конце концов, существует так много наноструктур, что прерывания планировщика Linux становятся постоянными, но упреждение легко обнаруживается с помощью счетчиков производительности, и его эффект совсем не похож на остановки TurboBoost.
24.00,33.75,24.45,20166,0,0
24.00,33.78,24.45,20302,0,0
24.00,33.78,24.45,20202,0,0
24.00,33.68,24.91,41082,0,0
24.00,33.31,24.90,40998,0,0
24.00,33.70,25.30,58986,3668,1
24.00,33.74,24.42,18798,0,0
24.00,33.74,24.45,20172,0,0
24.00,33.77,24.45,20156,0,0
24.00,33.78,24.45,20258,0,0
24.00,33.78,24.45,20240,0,0
24.00,33.77,24.42,18826,0,0
24.00,33.75,24.45,20372,0,0
24.00,33.76,24.42,18798,4081,1
24.00,33.74,24.41,18460,0,0
24.00,33.75,24.45,20234,0,0
24.00,33.77,24.45,20284,0,0
24.00,33.78,24.45,20150,0,0
24.00,33.78,24.45,20314,0,0
24.00,33.78,24.42,18766,0,0
24.00,33.71,25.36,61608,0,0
24.00,33.76,24.45,20336,0,0
24.00,33.78,24.45,20234,0,0
24.00,33.78,24.45,20210,0,0
24.00,33.78,24.45,20210,0,0
24.00,33.00,24.00,-10,0,0
24.00,33.00,24.00,4,0,0
24.00,33.00,24.00,18,0,0
24.00,33.00,24.00,2,4132,1
24.00,33.00,24.00,44,0,0
Выводы
Машины TurboBoost несут ответственность за несоответствие в RDTSC-REFTSC, Это расхождение можно использовать для определения того, что переход состояния TurboBoost с 3,3 ГГц на 3,4 ГГц занимает приблизительно 20500 опорных тактовых циклов (8,5 мкс) и срабатывает не позднее, чем примерно 250000 нс (250 мкс; 600000 опорных тактовых циклов) после входа в add_reference() когда процессор решает, что рабочая нагрузка является достаточно интенсивной, чтобы заслужить масштабирование частоты-напряжения.
Будущая работа
Необходимо провести дополнительные исследования, чтобы определить, как стоимость перехода зависит от частоты, и можно ли настроить оборудование, выбирающее состояние питания. Особый интерес для меня представляют "Turbo Attenuation Units", намеки на которые я видел в дальних уголках сети. Возможно, у оборудования Turbo есть настраиваемое временное окно? В настоящее время отношение времени, потраченного на принятие решения, к времени, потраченному на переход, составляет 30:1 (600us:20us). Это можно настроить?