Потерянные циклы на Intel? Несоответствие между RDTSC и CPU CLK UNHALTED.REF TSC
на последних процессорах (по крайней мере, в последнее десятилетие или около того) Intel предложила три счетчика производительности оборудования с фиксированной функцией, в дополнение к различным настраиваемым счетчикам производительности. Три фиксированных счетчика:
INST_RETIRED.ANY
CPU_CLK_UNHALTED.THREAD
CPU_CLK_UNHALTED.REF_TSC
первый подсчитывает отставные инструкции, второе число фактических циклов, и последнее, что нас интересует. Описание Для Тома 3 руководства разработчиков программного обеспечения Intel:
это событие подсчитывает количество контрольные циклы со скоростью TSC, когда ядро не в состоянии Halt, а не в стоп-часы ТМ государства. Этот ядро переходит в состояние остановки при выполнении инструкции HLT или инструкция MWAIT. Это событие не зависит от частоты ядра изменения (например, состояния P), но учитываются с той же частотой, что и время счетчик марок. Это событие может приблизить прошедшее время, пока ядро не был в состоянии остановки и не в состоянии TM stopclock.
так CPU-bound loop, я ожидаю, что это значение будет таким же, как и свободное значение TSC, считанное из rdstc, поскольку они должны расходиться только для инструкций остановленных циклов или что такое "состояние TM stopclock".
я проверяю это со следующим циклом (весь автономная демонстрация доступна на 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 ".6fn",
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); что просто плотная петля испаряющих магазинов, которые составленный by 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. The __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:
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 - это эффективная вычисленная истинная частота процессора за интервал и в основном показана ради любопытства и как быстрое подтверждение того, сколько turbo работает. Ratio соотношение REF_TSC и rdtsc столбцы. Я ожидал бы, что это будет очень близко к 1, но на практике мы видим, что он колеблется от 0.90 до 0.92 с большой дисперсией (я видел его как 0.8 на других запусках).
графически это выглядит примерно так2:
на rdstc звонок возвращается почти точно результаты1, в то время как счетчик PMU TSC находится повсюду, иногда почти на уровне 2300 МГц.
Если Я выключить turbo, однако, результаты гораздо более последовательны:
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%. Я не могу сказать точно что такое "TM stop-clock cycles", но я бы поспорил, что это" циклы терморегулирования", трюк, используемый для временного дросселирования процессора при достижении максимальной температуры. Тем не менее, я посмотрел на интегрированные показания термистора, и я никогда не видел, чтобы процессор сломался 60C, намного ниже 90C-100C, где termal управление (я думаю).
есть идеи, что это может быть? Существуют ли подразумеваемые "циклы остановки" для перехода между различными частотами турбонаддува? Это определенно происходит, так как коробка не тихая, и поэтому частота турбо прыгает вверх и вниз, когда другие ядра начинают и прекращают работать на фоновом режиме (максимальная частота турбо зависит непосредственно от количества активных ядер: на моем поле это 3.5, 3.3, 3.2, 3.1 GHz для 1, 2, 3 или 4 ядер активных, соответственно.)
1 на самом деле, какое-то время я действительно получал точно результаты до двух знаков после запятой: 2591.97 MHz - после каждой итерации. Затем что-то изменилось, и я не совсем уверен, что и есть небольшая вариация около 0,1% в rdstc результаты. Одна из возможностей-постепенная настройка часов, выполняемая подсистемой синхронизации Linux, чтобы привести локальное время кристалла в соответствие с ntpd определенное время. Возможно, это просто дрейф кристаллов - последний график выше показывает устойчивое увеличение измеряемого периода rdtsc каждый второй.
2 графики не соответствуют тем же запускам, что и значения, отображаемые в тексте, потому что я не собираюсь обновлять графики каждый раз, когда я изменяю формат вывода текста. Однако качественное поведение по существу одинаково на каждом прогоне.
1 ответов
TL; DR
несоответствие, которое вы наблюдаете между RDTSC и REFTSC и связано с переходами P-состояния TurboBoost. Во время этих переходов большая часть ядра, включая счетчик производительности фиксированной функции REF_TSC, остановлено для приблизительно 20000-21000 циклов (8.5 us), но rdtsc продолжается на своей инвариантной частоте. rdtsc вероятно, находится в изолированном домене питания и часов, потому что это так важно и из-за его документированного wallclock-like поведение.
на RDTSC-REFTSC противоречие
несоответствие проявляется как тенденция RDTSC в переоцененный REFTSC. Чем дольше программа работает, тем больше положительная разница RDTSC-REFTSC стремится быть. На очень длинных участках он может монтировать до 1%-2% или даже выше.
конечно, было замечено вами уже что overcounting исчезает когда TurboBoost отключено, которое можно сделать следующим образом при использовании intel_pstate:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
но это не говорит нам наверняка, что TurboBoost виноват в несоответствии; может быть, что более высокие P-состояния, включенные TurboBoost, съедают доступный запас, вызывая термическое дросселирование и остановки.
Возможно Регулирование?
TurboBoost динамическое разрешение шкалирования частоты и напряжения тока оппортунистически для того чтобы принять преимущество headroom в работая габарите (термальном или электрическом). Когда это возможно, TurboBoost затем будет масштабироваться частота ядра и напряжение процессора за пределы их номинального значения, тем самым улучшая производительность за счет более высокого энергопотребления.
более высокий расход энергии конечно увеличивает температуру и расход энергии сердечника. В конце концов, какой-то предел будет поражен, и TurboBoost придется снизить производительность.
защита от перегрева ТМ1?
я начал с изучения того, является ли схема терморегулирования (TCC) для теплового монитора 1 (TM1) или 2 (TM2) вызывает термическое дросселирование. TM1 уменьшает расход энергии путем вводить циклы стоп-часов TM, и эти одно из условий документированных для того чтобы привести к стопу REFTSC. TM2, с другой стороны, не стробирует часы; он только масштабирует частоту.
я изменил libpfc() чтобы я мог читать, выберите MSRs, в частности IA32_PACKAGE_THERM_STATUS и IA32_THERM_STATUS MSRs. Оба содержат статус только для чтения и чтение-запись, аппаратно-липкий флаг журнала для различных тепловых условий:
(The
IA32_PACKAGE_THERM_STATUSрегистр практически тот же)
в то время как некоторые из этих битов были иногда установлены (особенно при блокировке вентиляционных отверстий ноутбука!), они, похоже, не коррелируют с RDTSC overcounting, которое надежно произошло бы независимо от термального состояния.
Задействовать Обязанности Оборудования? C-Состояния Ординатура?
копание в другом месте в SDM для аппаратного обеспечения, подобного остановке, я столкнулся с HDC( аппаратным рабочим циклом), механизмом, с помощью которого ОС может вручную запрашивать процессор для работы только фиксированной доли времени; аппаратное обеспечение HDC реализует это, запустив процессор для 1-15 тактов за 16-тактовый период, и принудительный холостой ход это для оставшихся 15-1 тактов этого периода.
HDC предлагает очень полезные регистры, в частности MSRs:
-
IA32_THREAD_STALL: подсчитывает количество циклов в тупик из-за принудительного холостого хода на этом логическом процессоре. -
MSR_CORE_HDC_RESIDENCY: то же самое, что и выше, но для физического процессора подсчитывает циклы, когда один или несколько логических процессоров этого ядра работают на холостом ходу. -
MSR_PKG_HDC_SHALLOW_RESIDENCY: подсчитывает циклы, в которых пакет находился в состоянии C2, и по крайней мере один логический процессор работал на холостом ходу. -
MSR_PKG_HDC_DEEP_RESIDENCY: подсчитывает циклы, что пакет был в более глубокое (которое точно настраивается) C-Состояние и, по крайней мере, один логический процессор был силовым холостым.
дополнительные сведения см. В Томе Intel SDM 3, Глава 14,§14.5.1 Аппаратный Долг Велоспорт Интерфейс Программирования.
но мой процессор i7-4700MQ 2.4 GHz не поддерживает HDC, и так было для HDC.
иные источники регулирования?
копая еще немного в Intel SDM, я нашел очень-очень сочный MSR:MSR_CORE_PERF_LIMIT_REASONS. Этот регистр сообщает большое количество очень полезных статусов и липких бит журнала:
690H MSR_CORE_PERF_LIMIT_REASONS-пакет-индикатор отсечения частоты в ядрах процессора
- немного
0: PROCHOT статус- немного
1: Тепловое Состояние- немного
4: Графический Драйвер Статус. При установке частота уменьшается ниже запроса операционной системы из-за переопределения графического драйвера процессора.- немного
5: Автономное Использование На Основе Состояния Управления Частотой. При установке частота уменьшается ниже запроса операционной системы, поскольку процессор обнаружил, что использование низкое.- немного
6: Регулятор Напряжения Тепловой Оповещения Статус. Когда установлено, частота уменьшена ниже запрос операционной системы должный к термальному сигналу тревоги от регулятора напряжения тока.- немного
8: Электрическое Состояние Пункта Конструкции. Когда установлено, частота уменьшена под запросом операционной системы должным к электрическим ограничениям пункта конструкции (например максимальному потреблению электрического тока).- немного
9: Состояние Ограничения Мощности Ядра. При установке частота уменьшается ниже запроса операционной системы из-за уровня домена ограничение мощности.- немного
10: пакет-уровень ограничения мощности PL1 статус. При установке частота уменьшается ниже запроса операционной системы из-за ограничения мощности на уровне пакета PL1.- немного
11: пакет-уровень ограничения мощности PL2 статус. При установке частота уменьшается ниже запроса операционной системы из-за ограничения мощности на уровне пакета PL2.- немного
12: Максимальный Предел Турбо Статус. Когда установлено, частота уменьшена под запросом операционной системы должным к пределам турбо мульти-ядра.- немного
13: Состояние Амортизации Перехода Turbo. Когда установлено, частота уменьшена под запросом операционной системы должным к амортизации перехода Turbo. Это предотвращает ухудшение производительности из-за частых изменений рабочего коэффициента.- немного
16: PROCHOT Log- немного
17: Тепловые Журнала- немного
20: Журнал Графических Драйверов- немного
21: Автономный Журнал Управления Частотой На Основе Использования- немного
22: Регулятор Напряжения Тепловой Журнал Оповещения- немного
24: Электрический Журнал Пункта Дизайна- немного
25: Журнал Ограничения Мощности Ядра- немного
26: пакет-уровень ограничения мощности PL1 Log- немного
27: пакет-уровень ограничения мощности PL2 Log- немного
28: Max Turbo Limit Log- немного
29: Журнал Амортизации Перехода Turbo
pfc.ko теперь поддерживает этот MSR и демо печатает, какой из этих битов журнала активен. Этот pfc.ko водитель очищает липкие биты на каждом чтении.
я повторяю ваши эксперименты при печати битов, и мой процессор сообщает под очень большой нагрузкой (все 4 ядра/8 потоков активны) несколько ограничивающих факторов, включая Электрический Пункт Конструкции и Ограничение Мощности Ядра. The пакет уровня PL2 и Max Turbo Limit бита всегда ставим на моем процессоре по неизвестным мне причинам. Я также видел иногда Турбо Затухание Перехода.
в то время как ни один из этих битов точно не коррелировал с наличием RDTSC-REFTSC нестыковка, последний дал мне пищу для размышлений. Простосуществование of Турбо Переходного Затухания подразумевает, что переключение P-состояний имеет существенную стоимость, которая должна быть ограничена некоторым гистерезисным механизмом. Когда я не смог найти MSR, который посчитал эти переходы, я решил сделать следующее лучшее - я буду используйте величину RDTSC-REFTSC overcount для того чтобы охарактеризовать импликации представления перехода TurboBoost.
эксперимент
настройка эксперимента выглядит следующим образом. На моем процессоре i7-4700MQ, номинальной скорости 2.4 GHz и максимальной скорости Turbo 3.4 GHz, я отключу все ядра, кроме 0 (загрузочный процессор) и 3 (удобное ядро жертвы не пронумеровано 0 и не логический брат 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 образцов at
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 nanos):
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, можно надежно наблюдать overcounting тактовый цикл квантов чуть более 20000 тактов. Но они не из-за переходов User-OS.
здесь-это визуальное сюжет:
Насыщенные синие точки: 0 стандартных отклонений (близко к среднему)
насыщенные красные точки: +3 стандартных отклонения (выше среднего)
насыщенные зеленые точки: -3 стандартных отклонения (ниже)
существует заметная разница до, во время и после примерно 250000 наносекунд устойчивого уменьшения.
Nanos
перед порог, журналы 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 совершенно стабилизированный на 33x,RDTSC в синхронии с REFTSC в 24x скорость REF_XCLK (100 МГц), незначительное превышение, обычно 0 циклов, проведенных в ядре, и, таким образом, 0 переходов в ядро. Прерываний ядра займет примерно 3000 ссылочные циклы службы.
Nanos == 250000
при критическом пороге журнал содержит сгустки 20000 overcounts цикла, и overcounts очень хорошо коррелируют с нецелым расчетные значения мультипликатора между 33х и 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
Nanos > 250000
TurboBoost от 3.3 GHz до 3.4 GHz теперь происходит надежно. По мере увеличения наночастиц журналы заполняются примерно целыми кратными 20000-циклическими квантами. В конце концов, существует так много nanos, что прерывания планировщика Linux становятся постоянными светильниками, но preemption легко обнаруживается с помощью производительность счетчиков, и ее эффект совсем не похож на остановки 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 us) и запускается не позднее, чем около 250000 НС (250us; 600000 опорных тактовых циклов) после входа в add_reference(), когда процессор решает, что рабочая нагрузка достаточно интенсивна, чтобы заслужить масштабирование по частоте напряжения.
Будущей Работе
больше исследования необходимо сделать для того чтобы определить как цена перехода меняет с частотой, и Ли оборудование выбирая государство силы можно настроить. Особый интерес для меня представляют "блоки ослабления турбонаддува", намеки на которые я видел в дальних уголках сети. Возможно, оборудование Turbo имеет настраиваемое окно времени? В настоящий момент соотношение времени тратить решив потраченное время перехода составляет 30:1 (600us:20us). Его можно настроить?