Ответ 1
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, съедают доступный запас, приводя к термическому дросселю и остановкам.
Возможное дросселирование?
TurboBoost - это динамическое решение масштабирования частоты и напряжения, чтобы оппортунистически использовать преимущество в рабочей оболочке (тепловой или электрической). Когда возможно, TurboBoost затем увеличит частоту и напряжение ядра процессора выше их номинального значения, что улучшит производительность за счет более высокого энергопотребления.
Более высокая потребляемая мощность, конечно, увеличивает температуру ядра и потребление энергии. В конце концов, будет достигнут какой-то предел, и TurboBoost придется сбивать производительность.
Термическое демпфирование TM1?
Я начал с изучения того, вызывает ли терморегулирование (TCC) для Thermal Monitor 1 (TM1) или 2 (TM2) термическое дросселирование. TM1 снижает энергопотребление, вставляя циклы останова TM, и это одно из условий, задокументированных, чтобы привести к остановке REFTSC. TM2, с другой стороны, не закрывает часы; Он только масштабирует частоту.
Я изменил libpfc(), чтобы разрешить мне читать выбранные MSR, в частности MSR файлы IA32_PACKAGE_THERM_STATUS и 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: подсчитывает количество остановленных циклов из-за принудительного холостого хода на этом логическом процессоре. -
MSR_CORE_HDC_RESIDENCY: То же, что и выше, но для физического процессора, подсчитывает циклы, когда один или несколько логических процессоров этого ядра работают на холостом ходу. -
MSR_PKG_HDC_SHALLOW_RESIDENCY: подсчитывает циклы, в которых пакет находился в состоянии C2, и по крайней мере один логический процессор был принудительным. -
MSR_PKG_HDC_DEEP_RESIDENCY: подсчитывает циклы, в которых пакет находился в более глубоком (который точно настраивается). С-состояние и по крайней мере один логический процессор были принудительно-холостыми.
Для получения дополнительной информации см. раздел Intel SDM Volume 3, Chapter 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: Статус PROCHOT- Бит
1: Термический статус- Бит
4: Состояние графического драйвера. При установке частота уменьшается ниже запроса операционной системы из-за переопределения драйвера процессора.- Бит
5: Состояние автономного использования на основе использования на основе использования. Когда установлено, частота уменьшается ниже запроса операционной системы, потому что процессор обнаружил, что использование является низким.- Бит
6: Состояние теплового предупреждения регулятора напряжения. Когда установлено, частота уменьшается ниже запроса операционной системы из-за теплового сигнала от регулятора напряжения.- Бит
8: Статус точки электрического дизайна. При установке частота уменьшается ниже запроса операционной системы из-за ограничений электрической схемы (например, максимального потребления электрического тока).- Бит
9: Статус ограничения мощности ядра. Когда установлено, частота уменьшается ниже запроса операционной системы из-за ограничения мощности на уровне домена.- Бит
10: Ограничение мощности на уровне пакетов Состояние PL1. При установке частота уменьшается ниже запроса операционной системы из-за ограничения уровня PL1 на уровне пакета.- Бит
11: Уровень ограничения мощности на уровне пакета PL2. Когда установлено, частота уменьшается ниже запроса операционной системы из-за ограничения уровня PL2 на уровне пакета.- Бит
12: Максимальный уровень ограничения Turbo. Когда установлено, частота уменьшается ниже запроса операционной системы из-за многоядерных пределов турбонаддува.- Бит
13: Состояние затухания Turbo Transition. Когда установлено, частота уменьшается ниже запроса операционной системы из-за затухания перехода Turbo. Это предотвращает ухудшение производительности из-за частых изменений коэффициента работы.- Бит
16: Журнал PROCHOT- Бит
17: Термальный журнал- Бит
20: Журнал графического драйвера- Бит
21: Автономный журнал управления частотой на основе использования- Бит
22: Журнал температурного предупреждения регулятора напряжения- Бит
24: Журнал точек электрического проектирования- Бит
25: Журнал ограничения мощности ядра- Бит
26: Ограничение мощности на уровне пакетов Журнал PL1- Бит
27: Ограничение мощности на уровне пакетов Журнал PL2- Бит
28: Максимальный журнал ограничения скорости- Бит
29: Журнал затухания Turbo Transition
pfc.ko теперь поддерживает этот MSR, а demo печатает, какой из этих битов журнала активен. Драйвер pfc.ko очищает липкие биты при каждом чтении.
Я повторяю ваши эксперименты при печати битов, и мой процессор сообщает, что при очень большой нагрузке (все 4 ядра /8 потоков) несколько ограничивающих факторов, включая точку электрического дизайна и ограничение мощности ядра. Биты уровня PL2 и Max Turbo Limit всегда устанавливаются на моем CPU по неизвестным мне причинам. Я также иногда видел Turbo Transition Attenuation.
Хотя ни один из этих битов точно не коррелировал с наличием несоответствия RDTSC-REFTSC, последний бит дал мне пищу для размышлений. Простое существование Turbo Transition Attenuation подразумевает, что коммутация P-состояний имеет достаточно значительную стоимость, которая должна быть ограничена скоростью с помощью некоторого механизма гистерезиса. Когда я не смог найти MSR, который считал эти переходы, я решил сделать следующее самое лучшее - я буду использовать величину перерасчета RDTSC-REFTSC, чтобы охарактеризовать последствия перехода TurboBoost.
Эксперимент
Настройка эксперимента следующая. На моем процессоре i7-4700MQ, номинальной скорости 2,4 ГГц и максимальной скорости Turbo Speed 3,4 ГГц, я отключу все ядра, кроме 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
Я запускал приложение demo для 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
Я сделал несколько замечаний о бревнах, но один выделялся:
Для нано- ~ 250000, существует незначительная перерасчет RDTSC. Для наноs > ~ 250000 можно надежно наблюдать перерасчет квантов тактового цикла всего более 20000 тактов. Но они не связаны с переходами пользовательской ОС.
Вот визуальный сюжет:
Насыщенные голубые точки: 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, a RDTSC, который учитывается синхронно с REFTSC с частотой 24x, скоростью REF_XCLK (100 МГц), незначительной перерасчетностью, обычно 0 циклов, потраченными в ядре и, следовательно, 0 переходит в ядро. Прерывания ядра берут приблизительно 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
Наноs > 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.5us) и запускается не позднее, чем около 250000 нс (250 точек; 600000 опорных тактовых циклов) после входа в add_reference(), когда процессор решает, что рабочая нагрузка достаточно интенсивна, чтобы заслужить масштабирование частотного напряжения.
Будущая работа
Необходимо провести дополнительные исследования, чтобы определить, как изменяется стоимость перехода с частотой, и может ли быть настроено аппаратное обеспечение выбора состояния питания. Для меня особый интерес представляют "Turbo Attenuation Units", подсказки которых я видел в дальних точках Интернета. Возможно, оборудование Turbo имеет настраиваемый timewindow? В настоящее время соотношение времени, затрачиваемого на время перехода, составляет 30: 1 (600us: 20us). Можно ли его настроить?