Потерянные циклы на Intel? Несоответствие между rdtsc и CPU_CLK_UNHALTED.REF_TSC

На недавних процессорах (по крайней мере, в последнее десятилетие или около того) Intel предложила три счетчика производительности аппаратных средств с фиксированной функциональностью в дополнение к различным настраиваемым счетчикам производительности. Три фиксированных счетчика:

INST_RETIRED.ANY CPU_CLK_UNHALTED.THREAD CPU_CLK_UNHALTED.REF_TSC 

Первый подсчет отставных инструкций, второе число фактических циклов, а последнее – то, что нас интересует. Описание тома 3 руководства Intel Software Developers:

Это событие подсчитывает количество эталонных циклов при скорости TSC, когда kernel ​​не находится в состоянии остановки, а не в состоянии остановки TM. Ядро входит в состояние остановки, когда он запускает инструкцию HLT или инструкцию MWAIT. На это событие не влияют изменения частоты ядра (например, состояния P), но рассчитывается с той же частотой, что и счетчик временной метки. Это событие может приблизиться к прошедшему времени, в то время как kernel ​​не находится в состоянии остановки, а не в состоянии остановки TM.

Поэтому для цикла, привязанного к процессору, я ожидаю, что это значение будет таким же, как и свободное значение TSC, считываемое с rdstc , поскольку они должны расходиться только для инструкций с остановками циклов или того, что такое «состояние остановки в TM».

Я тестирую это со следующим циклом (вся отдельная демонстрация доступна на 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(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 – эффективная рассчитанная истинная частота процессора в течение интервала и в основном показана ради любопытства и в качестве быстрого подтверждения того, сколько турбо REF_TSC . Ratio – это отношение REF_TSC и rdtsc . Я ожидал бы, что это будет очень близко к 1, но на практике мы видим, что он колеблется от 0,90 до 0,92 с большой дисперсией (я видел его как 0,8 на других прогонах).

Графически это выглядит примерно так: 2 :

PMU tsc vs rdstc

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 должен быть таким же, как и предыдущий график):

PMU vs rdtsc (без турбо)

Теперь код просто запускает горячий цикл, и не должно быть никаких hlt или mwait , и, конечно же, ничего, что означало бы изменение более чем на 10%. Я не могу точно сказать, что такое «циклы останова TM», но я бы поспорил, что они «циклы остановки охлаждения», трюк, используемый для временного дросселирования ЦП при достижении максимальной температуры. Тем не менее, я посмотрел на встроенные термисторные показания, и я никогда не видел перелома процессора 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 Графики не соответствуют тем же запускам, что и значения, отображаемые в тексте, потому что я не собираюсь обновлять графики каждый раз, когда меняю формат вывода текста. Однако качественное поведение, по сути, одно и то же на каждом прогоне.

TL; DR

Несоответствие, которое вы наблюдаете между RDTSC и REFTSC и связано с переходами P-состояния TurboBoost. Во время этих переходов большая часть ядра, включая счетчик производительности фиксированной функции REF_TSC , останавливается примерно на 20000-21000 циклов (8.5us), но rdtsc продолжает свою инвариантную частоту. rdtsc , вероятно, находится в изолированной области мощности и часов, потому что это так важно и из-за его документированного поведения, похожего на Wallclock.

Несоответствие RDTSC-REFTSC

Расхождение проявляется как тенденция к RDTSC для перерасчета REFTSC . Чем дольше работает программа, тем более положительной является различие RDTSC-REFTSC . На очень длинных участках он может достигать 1% -2% или даже выше.

Конечно, уже было замечено, что перерасчет исчезает, когда TurboBoost отключен, что можно сделать следующим образом при использовании intel_pstate :

 echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo 

Но это не говорит нам наверняка, что TurboBoost виноват в несоответствии; Возможно, что более высокие P-состояния, поддерживаемые TurboBoost, съедают ansible запас, приводящий к термическому дросселированию и остановке.

Возможное дросселирование?

TurboBoost – это динамическое решение масштабирования частоты и напряжения, позволяющее оппортунистически использовать преимущество в рабочей оболочке (тепловой или электрической). Когда это возможно, TurboBoost затем увеличит частоту и напряжение ядра процессора выше их номинального значения, что улучшит производительность за счет более высокого энергопотребления.

Более высокая потребляемая мощность, конечно, увеличивает температуру ядра и потребление энергии. В конце концов, какой-то предел будет поражен, и TurboBoost придется сбивать производительность.

TM1 Thermal Throttling?

Я начал с изучения того, вызывает ли терморегулирование (TCC) для Thermal Monitor 1 (TM1) или 2 (TM2) термическое дросселирование. TM1 снижает потребляемую мощность, вставляя циклы останова TM, и это одно из условий, задокументированных, чтобы привести к остановке REFTSC . TM2, с другой стороны, не закрывает часы; Он только увеличивает частоту.

Я изменил libpfc() чтобы позволить мне читать выбранные MSR, в частности, IA32_PACKAGE_THERM_STATUS и IA32_THERM_STATUS MSR. Оба содержат статус «Только для чтения» и «Запись-запись», прикрепленный к аппаратным листам, для различных термических условий:

Содержимое регистра IA32_THERM_STATUS (Регистр IA32_PACKAGE_THERM_STATUS в основном одинаков)

Хотя некоторые из этих бит иногда устанавливались (особенно при блокировке вентиляционных отверстий для ноутбуков!), Они, похоже, не коррелировали с избыточным RDTSC , что было бы надежно происходить независимо от теплового статуса.

Аппаратное обеспечение? C-State Residency?

Копаясь в другом месте SDM для аппаратного обеспечения с секундомером, я столкнулся с HDC (Hardware Duty Cycle), механизмом, с помощью которого ОС может вручную запросить процессор для работы только фиксированной доли времени; Аппаратное обеспечение HDC реализует это, запустив процессор на 1-15 тактов в течение 16-тактного периода и принудительно перевернув его на оставшиеся 15-1 тактовых цикла этого периода.

HDC предлагает очень полезные регистры, в частности MSR:

  • IA32_THREAD_STALL : IA32_THREAD_STALL количество остановленных циклов из-за принудительного холостого хода на этом логическом процессоре.
  • MSR_CORE_HDC_RESIDENCY : То же, что и выше, но для физического процессора, подсчитывает циклы, когда один или несколько логических процессоров этого ядра работают на холостом ходу.
  • MSR_PKG_HDC_SHALLOW_RESIDENCY : MSR_PKG_HDC_SHALLOW_RESIDENCY циклы, в которых пакет находился в состоянии C2, и по крайней мере один логический процессор был принудительным.
  • MSR_PKG_HDC_DEEP_RESIDENCY : MSR_PKG_HDC_DEEP_RESIDENCY циклы, в которых пакет находился в более глубоком (который точно настраивается) C-состоянии и, по крайней мере, один логический процессор был принудительно-холостым.

Для получения дополнительной информации см. Раздел Intel SDM Volume 3, глава 14, раздел 14.5.1 Интерфейс программирования аппаратного обеспечения .

Но мой i7-4700MQ 2,4 ГГц CPU не поддерживает 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. Это предотвращает ухудшение производительности из-за частых изменений коэффициента работы.
  • Бит 16 : журнал PROCHOT
  • Бит 17 : Термальный журнал
  • Бит 20 : Журнал графических драйверов
  • Бит 21 : автономный журнал управления частотой на основе использования
  • Бит 22 : журнал температурного предупреждения регулятора напряжения
  • Бит 24 : журнал электрических точек проектирования
  • Бит 25 : Журнал ограничения мощности
  • Бит 26 : Ограничение мощности на уровне пакета PL1 Log
  • Бит 27 : Ограничение мощности на уровне пакета PL2 Log
  • Бит 28 : максимальный журнал ограничения скорости
  • Бит 29 : журнал затухания турбоперехода

pfc.ko теперь поддерживает этот MSR, а демоверсия печатает, какой из этих битов журнала активен. Драйвер pfc.ko очищает липкие биты при каждом чтении.

Я повторяю ваши эксперименты при печати бит, и мой процессор сообщает, что при очень большой нагрузке (все 4 ядра / 8 streamов активны) несколько ограничивающих факторов, включая точку электрического проектирования и ограничение мощности ядра . Биты уровня PL2 и Max Turbo Limit всегда устанавливаются на моем CPU по неизвестным мне причинам. Я также иногда видел Turbo Transition Attenuation .

Хотя ни один из этих бит точно не коррелировал с наличием несоответствия RDTSC-REFTSC , последний бит дал мне пищу для размышлений. Простое существование Turbo Transition Attenuation подразумевает, что коммутация P-состояний имеет достаточно значительную стоимость, которая должна быть ограничена по скорости с помощью некоторого механизма гистерезиса. Когда я не смог найти MSR, который считал эти переходы, я решил сделать следующее самое лучшее – я буду использовать величину RDTSC-REFTSC количества RDTSC-REFTSC REFTSC, чтобы охарактеризовать последствия перехода TurboBoost на производительность.

эксперимент

Настройка эксперимента следующая. На моем процессоре i7-4700MQ, номинальной скорости 2,4 ГГц и максимальной скорости Turbo Speed ​​3,4 ГГц, я отключу все ядра, кроме 0 (процессор загрузки) и 3 (удобный kernel ​​жертвы не пронумеровано 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 образцов на

 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 (eg 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 (eg 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 (eg 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 (eg Current) Core Power Limiting Package-Level PL1 Power Limiting * Package-Level PL2 Power Limiting * Max Turbo Limit (Multi-Core Turbo) Turbo Transition Attenuation 

Я сделал несколько замечаний по поводу бревен, но один выделялся:

Для наносов <~ 250000 существует незначительная перерасчет RDTSC. Для нанос> ~ 250000 можно надежно наблюдать перерасчет квантов тактового цикла всего более 20000 тактов. Но они не связаны с переходами пользовательской ОС.

Вот визуальный сюжет:

Изображение, показывающее квантованные штрафные санкции TurboBoost Насыщенные голубые точки: 0 стандартных отклонений (близко к среднему)

Насыщенные красные точки: +3 стандартных отклонения (выше среднего)

Насыщенные зеленые точки: -3 стандартных отклонения (ниже среднего)

Наблюдается заметная разница до, во время и после примерно 250000 наносекунд постоянного декремента.

Nanos <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 совершенно стабильно на 33x, RDTSC который рассчитывается синхронно с REFTSC с REFTSC 24x, скоростью REF_XCLK (100 МГц), пренебрежимо малой суммой, обычно 0 циклов, потраченных в ядре и, следовательно, 0 переходит в kernel. Прерывания ядра берут приблизительно 3000 эталонных циклов для обслуживания.

Nanos == 250000

При критическом пороге журнал содержит скопления 20000 циклов overcounts, а перерасчеты очень хорошо коррелируют с нецелочисленными оцененными значениями множителя между 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 становятся постоянными светильниками, но предотrotation легко обнаруживается с помощью счетчиков производительности, и его эффект совсем не похож на остановки 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.5us) и запускается не позднее, чем около 250000 нс ( add_reference() ; 600000 опорных тактовых циклов) после входа в add_reference() , когда процессор решает, что рабочая нагрузка достаточно интенсивна, чтобы заслужить масштабирование по частоте.

Будущая работа

Необходимо провести дополнительные исследования, чтобы определить, как изменяется стоимость перехода с частотой, и может ли быть настроено аппаратное обеспечение выбора состояния питания. Для меня особый интерес представляют «Turbo Attenuation Units», подсказки которых я видел в дальних точках Интернета. Возможно, оборудование Turbo имеет настраиваемый timewindow? В настоящее время соотношение времени, затрачиваемого на время перехода, составляет 30: 1 (600us: 20us). Можно ли его настроить?

  • C # самый быстрый способ смены массива
  • Производительность Cellfun и Simple Matlab Loop
  • MATLAB parfor медленнее, чем для - что не так?
  • Почему смещение MYSQL выше LIMIT замедляет запрос вниз?
  • Разница скоростей между оператором If-Else и Ternary в C ...?
  • Оптимизация кэширования файлов и HTTP2
  • Декодирование длины пробега в MATLAB
  • Есть ли гарантия выравнивания возврата адреса с помощью новой операции C ++?
  • Производительность bcp / BULK INSERT по сравнению с табличными параметрами
  • Заменить значения в списке с помощью Python
  • Как передавать значения на страницах ASP.net без использования сеанса
  • Давайте будем гением компьютера.