Установление пределов intel GPU в Ubuntu 17.04 больше не работает
Я использовал ПОМОЩНИКА Ubuntu 16.04 прежде, но недавно переключенный на 17,04, потому что это шло с обновленным thermald и я предположил, что это исправит ошибки как это для меня. У меня были проблемы с thermald в Ubuntu 16.04, подобной одному описанному там, но полагание, что это, как говорили, было зафиксировано в thermald (1.5.4-3) и Ubuntu 17.04, шло с обновленной версией по умолчанию, я предположил, что это будет работать лучше на меня в целом, с возможным, зафиксированным на всем протяжении системы также. Таким образом, я установил 17.04, попробовали его, все работало хорошо, таким образом, я мигрировал полностью.
Через некоторое время, хотя я встретился, очень странная проблема с системой, полностью игнорирующей, установила пределы ЦП. В 16,04 в только произошел со мной, когда intel GPU пытался работать над частотой, связанной с рабочим состоянием ЦП, которое было выше, затем ограничивает. Например, если я работаю:
sudo cat /sys/kernel/debug/dri/1/i915_ring_freq_table
Это - мой вывод:
GPU freq (MHz) Effective CPU freq (MHz) Effective Ring freq (MHz)
650 800 0
700 800 0
750 1400 0
800 1500 0
850 1600 0
900 1600 0
950 1700 0
1000 1800 0
1050 1900 0
1100 2000 0
Таким образом, если я хочу, чтобы мой ЦП работал над 1500 МГц макс. и не повышаюсь затем, что, это означает, что GPU должен быть ограничен 800 МГц и никогда не повышаться также, потому что они связаны, поскольку это - GPU, интегрированный в ЦП.
В Ubuntu 16.04, что я сделал, должен был вручную установить пределы GPU путем записи в /sys/kernel/debug/dri/1/i915_max_freq значение я хочу быть максимальным пределом мой GPU, может пойти. Когда я ограничиваю ЦП 1500 МГц, я также работал бы:
echo 800 | sudo tee /sys/kernel/debug/dri/1/i915_max_freq
И мой GPU останется диапазон скручивания жгутов, не портя рабочие частоты ЦП.
В Ubuntu 17.04, хотя, после пределов настроек GPU все еще идет полностью до 1100 МГц, который представляет любые бессмысленные пределы ЦП и перегревает процессор.
~$ sudo cat /sys/kernel/debug/dri/1/i915_max_freq
800
Поскольку Вы видите, что предел устанавливается и на месте. Теперь мы проверяем frequency_info:
~$ sudo cat /sys/kernel/debug/dri/1/i915_frequency_info
PM IER=0x00000070 IMR=0xffffff8f ISR=0x00000000 IIR=0x00000000, MASK=0x0000002a
pm_intr_keep: 0x00000004
GT_PERF_STATUS: 0x000016cb
Render p-state ratio: 22
Render p-state VID: 203
Render p-state limit: 255
RPSTAT1: 0x00041610
RPMODECTL: 0x00000d92
RPINCLIMIT: 0x000019fa
RPDECLIMIT: 0x00003a98
RPNSWREQ: 1100MHz
CAGF: 1100MHz
RP CUR UP EI: 7165 (9171us)
RP CUR UP: 7006 (8967us)
RP PREV UP: 6725 (8608us)
Up threshold: 85%
RP CUR DOWN EI: 1314 (1681us)
RP CUR DOWN: 1315 (1683us)
RP PREV DOWN: 23741 (30388us)
Down threshold: 60%
Lowest (RPN) frequency: 650MHz
Nominal (RP1) frequency: 650MHz
Max non-overclocked (RP0) frequency: 1100MHz
Max overclocked frequency: 1100MHz
Current freq: 1100 MHz
Actual freq: 1100 MHz
Idle freq: 650 MHz
Min freq: 650 MHz
Boost freq: 1100 MHz
Max freq: 1100 MHz
efficient (RPe) frequency: 650 MHz
Current CD clock frequency: 400000 kHz
Max CD clock frequency: 400000 kHz
Max pixel clock frequency: 360000 kHz
Мы видим, что текущая и фактическая частота в полном макс. 1100 МГц.
Это также ударяет предел игнорирования частоты ЦП, потому что ЦП не может понизиться, если GPU идет что высоко:
~$ sudo cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 2.00 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 1.50 GHz and 1.50 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz (asserted by call to hardware).
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 2.00 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 1.50 GHz and 1.50 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.00 GHz (asserted by call to hardware).
Как Вы видите, политика является диапазоном от 1,50 ГГц до 1.50 ГГц, но это ударено до макс. из-за GPU.
После того, как мы закрываем графическое приложение:
sudo cat /sys/kernel/debug/dri/1/i915_frequency_info
PM IER=0x00000070 IMR=0xffffff8f ISR=0x00000000 IIR=0x00000000,
[...]
CAGF: 650MHz
[...]
Lowest (RPN) frequency: 650MHz
Nominal (RP1) frequency: 650MHz
Max non-overclocked (RP0) frequency: 1100MHz
Max overclocked frequency: 1100MHz
Current freq: 650 MHz
Actual freq: 650 MHz
Idle freq: 650 MHz
Min freq: 650 MHz
Boost freq: 1100 MHz
Max freq: 1100 MHz
[...]
GPU вернулся к minumum, и ЦП теперь работает скручивание жгутов присвоенные пределы:
sudo cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 2.00 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 1.50 GHz and 1.50 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.12 GHz (asserted by call to hardware).
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 2.00 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 1.50 GHz and 1.50 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 1.49 GHz (asserted by call to hardware).
Вопрос: как я делаю intel GPU для следования за установленным пределом в Ubuntu 17.04, таким образом, это прекращает бездельничать с моим пределом ЦП, и почему это игнорирует пределы, которые работали в 16,04?
Обновление: После ввода по абсолютному адресу вокруг я нашел эту вещь:
sudo cat /sys/kernel/debug/dri/0/i915_rps_boost_info
RPS enabled? 1
GPU busy? yes [1 requests]
CPU waiting? 0
Frequency requested 650
min hard:650, soft:650; max soft:700, hard:1100
idle:650, efficient:650, boost:1100
Xorg [1221]: 591 boosts
Kernel (anonymous) boosts: 8
RPS Autotuning (current "low power" window):
Avg. up: 0% [above threshold? 95%]
Avg. down: 0% [below threshold? 85%]
Каков этот "RPS", и это может быть причина, почему GPU 'повышает' к максимуму, игнорирующему установленные пределы?
1 ответ
Найденное решение и причина моей проблемы - это было повышение RPS, которое игнорировало набор gpu предел частоты.
Вместо того, чтобы установить предел через/sys/kernel/debug/dri/1/i915_max_freq, я переключился на установку его в/sys/class/drm/card1, параметры gt_max_freq_mhz и gt_boost_freq_mhz. После установления предела в i915_max_freq он не ограничил бы частоту повышения, поэтому когда система запросит повышение, он повысит его для ограничения указанный в gt_boost_freq_mhz, игнорируя то, что Вы устанавливаете.
Путем выполнения:
echo 800 | sudo tee /sys/class/drm/card1/gt_max_freq_mhz
echo 800 | sudo tee /sys/class/drm/card1/gt_boost_freq_mhz
Я установил пределы и к нормальным и к повышенным значениям, и система больше не раздвигает GPU прошлые границы, что означает, что предел ЦП не будет затронут ни один в моем случае.
sudo cat /sys/kernel/debug/dri/1/i915_rps_boost_info
RPS enabled? 1
GPU busy? yes [32 requests]
CPU waiting? 0
Frequency requested 800
min hard:650, soft:650; max soft:800, hard:1100
idle:650, efficient:650, boost:800
[...]
Шаги для применения этого решения:
1) Считайте таблицу в/sys/kernel/debug/dri/0/i915_ring_freq_table (или/sys/kernel/debug/dri/1/i915_ring_freq_table в некоторых случаях:
sudo cat /sys/kernel/debug/dri/0/i915_ring_freq_table
Найдите частоту ЦП, которая является скручиванием жгутов предел ЦП, который Вы хотите и ищете частоту GPU, связанную с ним, это будет предел, который необходимо установить для GPU.
2) Установите предел для частоты GPU путем записи в gt_max_freq_mhz, и gt_boost_freq_mhz, расположенный в/sys/class/drm/card0 (может быть cardX в зависимости от ситуации, проверить вручную в случае необходимости):
echo [GPU_frequency_limit] | sudo tee /sys/class/drm/cardX/gt_max_freq_mhz /sys/class/drm/cardX/gt_boost_freq_mhz
Например:
echo 800 | sudo tee /sys/class/drm/card0/gt_max_freq_mhz /sys/class/drm/card0/gt_boost_freq_mhz
3) Проверьте, пошли ли пределы канавка (изменитесь 0 на свои X значений при использовании cardX:
sudo cat /sys/kernel/debug/dri/0/i915_rps_boost_info
Ваше макс. мягкое и значения повышения должны теперь быть изменены, на какой Вы устанавливаете.
Знайте, что ограничение частоты GPU может уменьшить Вашу производительность OpenGL.
Если Вы не хотите использовать первое решение, можно попробовать альтернативу снизу.
Существует другое возможное альтернативное решение, которое не работает на меня из-за ограничения BIOS, но может работать на кого-то еще, который ограничивает предел питания пакета, как был предложен @spandruvada от Intel на GitHub thermald поток проблемы.
Сначала Вы видите текущее значение путем чтения/sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw:
sudo cat /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
Затем Вы пытаетесь изменить предельное значение путем выполнения:
echo [reduced_power_value] | sudo tee /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
Например, в моем случае я имел 35000000 как начальное значение, и хотят изменить его на 30000000:
echo 30000000 | sudo tee /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
Если Вы не получите "Доступных данных" после попытки записать в него, любой, который это просто отключено (который может быть проверен путем чтения/sys/class/powercap/intel-rapl/intel-rapl:0/enabled, то будет 0, если это будет отключено), или это заблокировано BIOS. Если Вы не можете включить его путем записи 1 для "разрешения" опции, проверьте dmesg на сообщение об ошибке (после того, как, пытаясь записать в constraint_0_power_limit_uw:
dmesg | grep powercap
[29580.025164] powercap intel-rapl:0: package locked by BIOS, monitoring only
Если Вы будете видеть "заблокированный BIOS то", необходимо будет включить его в BIOS вручную, если Вы не можете сделать этого, то Вы не можете управлять им, и этот метод не для Вас. Из того, что я понимаю, если Вам включили его, и работа, thermald должен корректироваться, они оценивают за Вас автоматически без Вас бывший должный изменить их вручную.
Проблема о GitHub с этим предложением
Если Вы хотите использовать этот метод вручную, еще некоторые детали об этом здесь.