Intel idle max cstate что значит

Обновлено: 07.07.2024

В статье описываются используемые в Linux методы получения информации об используемом процессоре и его состоянии (температура, частота, задушенность), управление частотой процессора, загрузка микрокода, модули msr и cpuid, привязка процесса и обработчика прерывания к конкретному процессору (ядру), особенности работы NUMA.

Начальную информацию о процессоре можно получить с помощью команды dmesg:

Далее необходимо заглянуть в /proc/cpuinfo:

Более подробную (400 строк) информацию можно получить с помощью команды x86info (ключи: -a -v).

  • type (всегда 0?)
  • family (15 - NetBirst, 6 - Core)
  • model
  • stepping

А также через DMI интерфейс: "dmidecode -t 4" (собственно процессор) и "dmidecode -t 7" (кеш).

  • type - Data, Instruction, Unified
  • level - L1, L2, L3
  • size
  • ways_of_associativity
  • shared_cpu_map - битовая карта ЦП, которые разделяют данный кеш
  • coherency_line_size - ?
  • number_of_sets - ?
  • physical_line_partition - ?
  • physical_package_id - номер чипа
  • core_id - номер ядра в чипе
  • core_siblings - битовая карта соседних по чипу ЦП
  • thread_siblings - битовая карта соседних по SMT (HT) ЦП

Модуль acpi-cpufreq конфликтует со встроенной в ядро обработкой Intel P-state и не загружается, так что /proc/acpi в CentOS 7 пуст.

Информация о возможностях по управлению питанием и throttling от ACPI:

И "lshal -t -l" (устарело).

Предельно допустимая температура процессора (материнской платы, системы):

Утилита lscpu выдаёт информацию об архитектуре, битности, порядке байт, количестве ядер, количестве потоков на ядро, сокетов, узлов NUMA, модель и ревизия (официальная частота), текущая частота, виртуализация, размеры кешей, распределение ЦП по узлам NUMA; ключ "-e" вызывает выдачу в виде таблицы

Модуль acpi-cpufreq конфликтует со встроенной в ядро обработкой Intel P-state и не загружается,

Получение информации о текущей температуре процессора (материнской платы):

Получение информации о питании процессора (текущее состояние, список возможных состояний, граф переходов и число переходов по каждой ветви; C1 - состояние после команды HLT; C1E - улучшенный вариант, сбрасывает множитель частоты процессора до минимально возможного значения (2.8GHz для P4 660)):

Управление частотой процессора позволяет регулировать энергопотребление компьютера. Подсистема управления частотой процессора в ядре Linux позволяет подключать управляющие модули для различных архитектур и извещать подсистемы ядра, которые зависят от частоты процессора, при изменении частоты или политики управления частотой. Некоторые системы могут изменять частоту самостоятельно без вмешательства программы. Для таких систем устанавливается политика изменения частоты, а также верхний и нижний пределы частоты. Для других систем требуется вмешательство программы при каждом изменении частоты. Для них устанавливается специальный управляющий модуль - регулятор (гувернёр, governor) и параметры для него.

  • affected_cpus
  • cpuinfo_cur_freq (текущая частота процессора, в КГц)
  • cpuinfo_max_freq (максимально возможная частота процессора, в КГц)
  • cpuinfo_min_freq (минимально возможная частота процессора, в КГц)
  • scaling_available_frequencies (перечень допустимых частот процессора, в КГц)
  • scaling_available_governors (перечень допустимых регуляторов)
  • scaling_cur_freq ()
  • scaling_driver (используемый архитектурнозависимый модуль управления частотой)
  • scaling_governor (используемый регулятор; для смены регулятора записать сюда его имя)
  • scaling_max_freq (максимальная частота процессора, которую будет устанавливать регулятор или обработчик политики)
  • scaling_min_freq (минимальная частота процессора, которую будет устанавливать регулятор или обработчик политики)
  • scaling_setspeed (для установки частоты записать сюда значение, в КГц)
  • userspace (модуль cpufreq_userspace, частота устанавливается прикладной программой или просто командой echo)
  • powersave (модуль cpufreq_powersave, устанавливает наименьшую разрешённую частоту)
  • performance (модуль cpufreq_performance, устанавливает наибольшую разрешённую частоту)
  • ondemand (модуль cpufreq_ondemand, частота процессора устанавливается в зависимости от нагрузки), управляющие параметры в подкаталоге ondemand:
    • ignore_nice_load (0; игнорировать нагрузку, создаваемую низкоприоритетными процессами)
    • sampling_rate (1000000 микросекунд; позволяет установить частоту опроса нагрузки)
    • sampling_rate_max (500000000; максимально возможное значение sampling_rate)
    • sampling_rate_min (500000; минимально возможное значение sampling_rate)
    • up_threshold (80%; при какой нагрузке в интервале между опросами увеличивать частоту процессора)
    • sampling_down_factor (1; сколько интервалов пониженной нагрузки выжидать перед понижением частоты процессора)
    • freq_step (5% от максимально возможной частоты процессора; шаг изменения частоты процессора; значение 100 даёт поведение эквивалентное поведению регулятора ondemand)
    • down_threshold (20%; при какой нагрузке в интервале между опросами уменьшать частоту процессора)
    • time_in_state (для каждой возможной частоты процессора выводится общее время, когда процессор работал на этой частоте, единица - 10 мс)
    • total_trans (количество изменений частоты процессора)
    • trans_table (матрица числа переходов от одной частоты процессора к другой; требуется CONFIG_CPU_FREQ_STAT_DETAILS при генерации ядра)

    Устанавливать регуляторы и частоты можно записывая желаемые значения в /sys/devices/system/cpu/cpu0/cpufreq/ (требуются прва суперпользователя) или используя аплет cpufreq-selector из пакета gnome-applets (позволяет устанавливать тип регулятора и частоту для регулятора userspace; права доступа устанавливаются обычным механизмом consolehelper и PAM).

    • --cpu номер-процессора
    • --min минимальная-частота-для-регулятора
    • --max максимальная-частота-для-регулятора
    • --governor регулятор
    • --freq частота (только для регулятора userspace)
    • USR1 - установить максимальную скорость
    • USR2 - установить минимальную скорость

    gkrellm имеет встраиваемый модуль gkrellm-freq, позволяющий узнать текущее значение текущее значение частоты процессора.

    • /sys/devices/system/cpu/intel_pstate/max_perf_pct
    • /sys/devices/system/cpu/intel_pstate/min_perf_pct
    • /sys/devices/system/cpu/intel_pstate/no_turbo
    • /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor (из /sys/devices/system/cpu/cpuX/cpufreq/scaling_available_governors - performance и powersave)

    Утилита "cpupower frequency-info" выдаёт информацию о ЦП, драйвере управления частотой, частоты, гувернёрам, турбо-режимам. "cpupower monitor -m Mperf" - текущая частота каждого ядра.

    Утилита x86_energy_perf_policy позволяет задать предпочтительный режим работы ЦП (performance, normal, powersave, смещение от 0 (performance) до 15 (powersave)).

    Запрет понижать частоту процессора достигается использованием параметров ядра processor.max_cstate=1, intel_idle.max_cstate=0 [и idle=poll] (увеличивается потребление электричества).

    TM1 (Thermal Monitoring 1) - понижение нагрева процессора вставлением пустых циклов. Вызывает проблемы у других частей компьютера.

    TM2 - понижение напряжения и частоты.

    Получение информации о текущем состоянии

    • ЦП с поддержкой Turbo Boost
    • включение Turbo Boost в BIOS
    • включение EIST (Enable Enhanced Intel SpeedStep Technology) в BIOS
    • адекватное охлаждение
    • достаточно новое ядро (RHEL 4.7, RHEL 5.3)
    • modprobe acpi-cpufreq
    • echo performance > /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor
    • потребляемый ток и мощность при текущей загрузке не превышают определённых изготовителем

    acpi-cpufreq для обозначения турборежима использует фиктивную частоту (3501000 вместо 3500000)

    Универсальная ручка управления включением режимов Turbo Boost и Turbo-Core - /sys/devices/system/cpu/cpufreq/boost (/sys/devices/system/cpu/intel_pstate/no_turbo?). Не поддерживается модулем intel_pstate.

    Утилита turbostat позволяет собрать статистику при выполнении указанной программы (возможности процессора по частоте при различном количестве активных ядер, частота, температура, мощность ЦП и ОП, режим).

    Утилита microcode_ctl загружает микрокод (исправленная прошивка) для процессоров Intel (требуется поддержка модуля ядра microcode, при загрузке создаётся символьное устройство /dev/cpu/microcode, 10:184). Собственно микрокод лежит в файле /etc/firmware/microcode.dat. Имеет ли смысл его обновлять при каждой загрузке?

    При загрузке модуля msr создаётся символьное устройство (/dev/cpu/0/msr, 202:0). Используется centrino-decode (декодирует информацию о напряжении питания процессора и соотношении частот процессора и системной шины).

    При загрузке модуля cpuid создаётся символьное устройство (/dev/cpu/0/cpuid, 203:0). Используется в правилах udev. Зачем это?

    • --pid [маска-процессоров] номер-процесса
    • --cpu-list список-процессоров (через запятую, интервалы через '-')
    • маска-процессоров -- запускаемая-команда аргументы

    Привязка обработки прерывания к процессору: узнать номер прерывания (lspci -v), записать битовую маску допустимых процессоров в /proc/irq/номер-прерывания/smp_affinity.

    CC-NUMA (Cache Coherent Non Uniform Memory Access) - система с неоднородным (в т.ч. по длительности; в 1.5 раза для Nehalem и Barcelona) доступом процессоров к узлам общей памяти с обеспечением когерентности кешей процессоров.

    Ядро Linux 2.6 имеет поддержку CC-NUMA в виде политики выделения памяти относительно узлов памяти (mempolicy.h: set_mempolicy(2), get_mempolicy(2), mbind(2)). По умолчанию, используется системная политика выделения памяти В качестве системной политики при загрузке используется политика поочерёдного выделения из узлов памяти с достаточным количеством свободной памяти, а при работе - политика локального выделения. Процесс может запросить использование другой политики для всех последующих своих запросов (и запросов своих наследников) или отдельную политику для запросов в отдельной области виртуальной памяти (только анонимные области, не наследуется). Отдельные политики могут быть установлены для разделяемых объектов. Политика состоит из режима работы (MPOL_DEFAULT - использовать политику исходя из области; MPOL_BIND - выделять память из ближайшего узла только из указанного списка узлов; MPOL_PREFERRED - выделять память из указанного узла, при недостатке памяти из ближайшего узла, при пустом списке узлов выбирается локальный узел (на котором запустилась первая нить); MPOL_INTERLEAVED - поочерёдное выделение из списка узлов). При свопировании страницы информация об узле страницы теряется. Для области памяти (определяется начальным адресом и длиной) можно задать политику выделения (VMA policy); задаются модификаторы режима (MPOL_MF_STRICT - все страницы д.б. на заданном узле; MPOL_MF_MOVE - попытаться переместить неправильно распределённые эксклюзивные страницы; MPOL_MF_MOVEALL - попытаться переместить все неправильно распределённые страницы; MPOL_F_STATIC_NODES - не перемещать страницы после смены списка узлов; MPOL_F_RELATIVE_NODES) и список допустимых узлов.

    • numa=off (считать всю память одним узлом)
    • numa=noacpi (не учитывать таблицу SRAT)
    • numa=fake=параметры (имитировать требуемую конфигурацию NUMA, см. fake-numa-for-cpusets)
    • numa=hotadd=процент (что такое hotadd память?)
    • cpumap - битовая карта ЦП узла
    • distance - список (по числу узлов) относительной "стоимости" обращения ЦП данного узла к памяти каждого узла
    • meminfo - разнообразная статистика наличия и использования памяти
    • numastat - количество попаданий и промахов запросов к памяти в свой узел
    • cpuX/ - ссылка на описание каждого процессора узла
    • cpus - список номеров ЦП и интервалов
    • mems - список узлов памяти и интервалов
    • memory_migrate - перемещать страницы памяти в разрешённые узлы при изменении настроек и перемещении процессов
    • cpu_exclusive - список ЦП является исключительным
    • mem_exclusive - список узлов памяти является исключительным
    • mem_hardwall - ядро не будет размещать здесь общие данные (с 2.6.26, ранее функциональность включалась при mem_exclusive=1)
    • memory_pressure - уровень обмена страниц внутри набора (paging pressure rate), может учитываться пакетным планировщиком, выражается в запросах в секунду за последние 10 секунд на 1000
    • memory_pressure_enabled - включает вычисление memory_pressure, представлен только для корневого набора
    • memory_spread_page - разрешить размещать буфера файловой системы (page cache) для процессов из набора по всем допустимым узлам вместо узла, на котором процесс выполняется
    • memory_spread_slab - разрешить размещать буфера slab (каталоги и inode) для процессов из набора по всем допустимым узлам вместо узла, на котором процесс выполняется
    • notify_on_release - запуск программы /sbin/cpuset_release_agent при завершении последнего процесса набора
    • sched_load_balance - планировщик будет использовать алгоритм балансировки нагрузки; включён по умолчанию, все ЦП должны быть в едином домене балансировки у планировщика заданий (с 2.6.24)
    • sched_relax_domain_level - интервал поиска перегруженного ЦП для миграции процесса на себя, если наша очередь задач пуста (-1: использовать системные установки, 0: не искать, 1: внутри HT, 2: ядра внутри пакета, 3: внутри узла, 4 - ?, 5 - по всей системе )(с 2.6.26, но в RHEL 5.3 есть)
    • tasks - список процессов, привязанных к набору (по одному на строке), сюда надо вписать номер процесса (по одному на строке), который нужно привязать к данному набору; для удаления процесса впишите его номер в верхний набор

    После переноса задачи tasks включающего набора вся информация меняется (/dev/cpuset/. /tasks, /proc/. /cpuset), но планировщик продолжает придерживать процесс на старом наборе ЦП (RHEL 5.4) .

    /proc/номер-процесса/status содержит новые строки о допустимых ЦП и узлах памяти.

    /proc/номер-процесса/cpuset содержит имя набора cpuset.

    /proc/номер-процесса/numa_maps рассказывает о каждом сегменте памяти: начальный адрес (конечный в maps), политику выделения памяти, тип (anon, heap, stack, file=имя), сколько страниц выделено из каждого узла NUMA-памяти.

    Пакеты numactl и numactrl-devel содержат утилиты и библиотеки более высокого уровня, чем системные вызовы. Утилита numastat выдаёт для каждого узла памяти статистику о использовании её для "своих" и "чужих" ЦП. Утилита memhog предназначена для тестирования производительности различных режимов использования памяти. Утилита migratepages плозволяет переместить содержимое страниц памяти с одного узла на другой. Утилита numademo позволяет протестировать производительность сочетаний свой/чужой для различных узлов памяти; демонстрирует расхождение в пропускной способности памяти в 1.5 раза для систем с использованием QPI/HT при правильном и неправильном распределении процессов по ЦП и узлам памяти (перепутаны Min и Max?):

    Стал я тут недавно 'счастливым' обладателем нетбука на базе Atom N270. Windows XP, естественно для меня, был немедленно выкинут с жёсткого диска и заменён Linux'ом. И всё было хорошо… где-то минут 15, пока процессор (вообще, конечно, все вам скажут, что не процессор, а чипсет, но всякие тесты, вроде кручения бесконечных пустых циклов в bash показали, что именно процессор) не стал чрезмерно горячим в процессе установки всяких разных пакетов (я вообще не понимаю, откуда Intel взяла оценку для TDP N270 в 2.5Вт).

    Другая ситуация. У моего знакомого довольно пожилой ноутбук ASUS с достаточно странными настройками ACPI, в таблицах которого записано, что включать throttling нужно при температуре системы в 89 градусов Цельсия, а отрубать систему от критического перегрева при температуре в 81 градус.

    Эмс… Вы не сочтите это всё антипиаром ASUS и Intel, ибо (я уверен) на других ноут(нет)буках с другими x86-процессорами вполне появляются схожие проблемы, и этот пост о том, как их решать, а не о том, какие праАативные флагманы IT… И вообще, я фанат ARM'ов… Так что для меня, что Intel, что AMD — одинаковое x86-зло… Но просто факт остаётся фактом. В некоторых старых моделях ноутбуков от ASUS кривые таблицы ACPI, а Atom'ы греются.

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

    Проблема только в том, что стандартные рецепты манипулирования только лишь power-уровнями процессора в Linux (при помощи подсистемы cpufreq), которые раздаются на всех форумах направо и налево, недостаточно эффективны. Тот же Atom ощутимо греется находясь и в самом 'экономном' режиме, а моему знакомому в работе периодически нужна высокая производительность процессора, однако не ценой отключения по критической температуре. И при этом сброс процессора его ноутбука в 'экономный' режим при повышении температуры от перегрева не спасал.

    В общем, проблемы надо как-то решать. Собственно вот, где-то на троечку с плюсом их решить получилось, решение описываю ниже с некоторыми подробностями, о которых редко пишут на user-форумах Linux (и вообще, я даже и сам не понял, откуда я всё это решение раздобыл :).

    Итак. Сперва немного теории.

    1. Режимы работы процессора.

    У любого уважающего себя x86-процессора режимов работы очень много. Они все описываются в жутко объёмном документе громко именуемом ACPI Specification. И кратко их можно охарактеризовать следующим образом.

    Режимы процессора. Эти состояния называются CN, где N — некоторая цифирька от 0, 1, 2, 3 до фантазии разработчиков этого процессора. Кажется, Opteron'ы умеют засыпать аж в режиме C8.

    Режим C0 — это рабочий режим, в котором процессор исполняет инструкции. А C1,… — режимы сна. В эти режимы ядро операционной системы переводит процессор в те моменты, когда осознаёт, что, в общем-то, никакой код она выполнять не должна (например, все нити-процессы ждут каких-то данных для продолжения работы, или пользователь сам даёт системе указание заснуть). Режимы эти отличаются несколькими параметрами. Самые главные из них это:

    (1) времена входа и выхода из этого режима, latency, то есть, с какой задержкой проснётся процессор при наступлении какого-нибудь значимого аппаратного события (например, возникновения сигнала прерывания от какого-нибудь устройства);

    (2) продолжает ли процессор во время сна обеспечивать какую-то функциональность. Например, продолжает ли он обеспечивать согласованность содержимого своего кэша с содержимым RAM.

    Стандарт ACPI говорит нам: чем больше N в CN, тем больше задержки по входу/выходу в/из этого режима, и тем меньшую функциональность поддерживает процессор.

    Обычно, в режиме C1 процессор засыпает неглубоко. Это сон, в который он впадает по исполнению инструкции hlt. Засыпает/просыпается он быстро в этом режиме, и все его системы активны. В режиме С2 он засыпает/просыпается медленней, многие подсистемы в нём отключается, а в режиме C3, он перестаёт отслеживать запросы в RAM, чтобы согласовывать содержимое своего кэша с памятью.

    Задержки здесь важны, чтобы ядро ОС могло правильно программировать таймеры, чтобы процессор проснулся как раз к моменту окончания sleep-интервала, запрошенного какими-нибудь процессами: если процесс запросил sleep в одну секунду, а задержка для входа и выхода из состояния C2 у процессора занимает .1 секунду, то ядро должно запрограммировать таймер на тик и генерацию прерывания через .9 секунд. Примитивный пример, но, надеюсь, достаточно иллюстративный.

    Во время активности системы (хабрачеловек на отправил свой компьютер в с suspend) процессор отправляют спать максимум в режим С2 (согласование кэшей — штука серьёзная). А в состояние C3 его переводят только при нажатии пользователем кнопочки sleep или запуском им команды
    pm-suspend .

    Полюбоваться тем, как спится ядрам вашего процессора можно командой

    Естественно, CPU0 нужно заменить на номер того процессора, состояние которого вы хотите узнать.

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

    В общем, вот. Больше тут сказать нечего. Режимы эти обозначаются обычно PN, где N от 0 до… и чем больше N, тем меньше частота и энергопотребление. Посмотреть же возможные P-состояния можно так:

    На самом деле частоту у современного процессора можно варьировать более плавно. Например, у данного вот Athlon II X2 её можно менять с шагом в 100MHz, но Linux показывает здесь и использует именно P-состояния, описанные в таблицах ACPI, то есть точки, в которых меняется и напряжение на ядре. Может быть, это будет изменено в будущих версиях ядра.

    Но это ещё не всё. Работая в некотором режиме производительности процессор может находится в режиме пропуска тактов — T-состоянии. Опять же, режим T0 означает, что такты процессор не пропускает, а Т7, означает, что процессор использует только каждый 8 такт тактового генератора для своей работы.

    Понятно, что чем больше тактов процессор пропускает, тем меньше он греется. Throttle-режимы появились в процессоре Pentium4 и активно там использовались для того, чтобы не допускать перегрева сего чрезмерно горячего произведения инженерного гения (или безумия… кому как больше нравится :) одна система replay'я чего стоит. Ну да ладно, то дела минувших лет).

    Посмотреть на возможные T-состояния можно так:

    Если в режимы С1, С2, С3 ядро переводит процессор вполне самостоятельно, как только обнаруживает в таблицах ACPI описание способности процессора к такому переходу (для этого должен быть загружен драйвер processor.ko), то для перевода процессора между P-состояниями ему нужны модули подсистемы Cpufreq.

    Здесь есть два основных компонента — драйверы для процессоров, которые могут распознавать допустимые P-режимы и водить процессор между ними, и управляющие. Драйверы они и в cpufreq драйверы, а вот управляющие — занятные зверушки.

    Управляющий — это модуль ядра, который реализуют некоторую политику перевода процессора из одного P-режима, в другой. Например, управляющий powersave держит процессор на самом экономном из возможных P-режимов (минимум и максимум ограничены возможностями оборудования, настройками cpufreq и интерфейсом ограничений). Или вот, например, управляющий ondemand при обнаружении того, что загрузка процессора достигла некоторого порога (который можно задать через настройки) сразу же отправляет его в самое производительное из допустимых P-режимов и держит его там пока нагрузка на процессор не снизится ниже некого порогового значения (пока этот порог менять нельзя, впрочем, есть более гибкий управляющий conservative).

    А за более подробной информацией желающие могут посмотреть в директорию:

    Эта занятная зверушка умеет делать вот что. Она может отслеживать некоторые параметры системы, в том числе и важные для решаемой задачи: (1) уровень температуры в различных температурных зонах компьютера и (2) уровень загрузки процессора вычислениями. А на основании полученных данных она может поменять настройки подсистемы cpufreq в ядре, или выполнить некую команду.

    Руководствуется cpufreqd в своей нелёгкой жизни описанием профилей и правил, взятых из конфигурационного файла. Профили — это описания неких действий, например: выбрать управляющего powersave и минимальную частоту выставить в 30% от максимально доступной, и выполнить команду 'echo Hello World' в оболочке.

    Правила — это списки условий, которые cpufreqd периодически проверяет и оценивает, выставляет им баллы за соответствие текущей ситуации, а потом применяет то правило, которое получает наивысшую оценку. Выполнение правила — это исполнение указаний в связанном с правилом профиле.

    Собственно вот. Всё просто. И уже вырисовывается план действий: нужно настроить cpufreqd так, чтобы при повышении температуры за какой-то порог он переводил процессор в самое экономичное из P-состояний, и заставлял CPU экономить, экономить и ещё раз экономить.

    А при нормальной температуре, он держал бы CPU при политике ondemand, например, чтобы и производительности хватало, и грелось бы не очень сильно всё при простое системы.

    4. Немного лирики.

    К сожалению, с процессорами от Intel сей фокус не проходит :(. Просто наболело (сколько сражался со своим Atom и с P3 знакомого), поэтому напишу. Вот, например, с официально 25Ваттным Turion X2 у меня вообще никаких проблем не возникало. Я включал управляющего conservative для обоих ядер процессора и спокойно себе работал. Замечая существенный нагрев ноутбука только при действительно серьёзных нагрузках вроде кодирования видео.

    Управляющий conservative похож на ondemand. Только он более плавный. Когда conservative обнаруживает, что вычислительная нагрузка на процессор возросла за некий период наблюдения до некого порогового значения (80% по-умолчанию) он переводит процессор в более производительный P-режим. Когда он замечает, что она упала ниже другого порога (20%), то он переводит процессор в менее производительны P-режим. Это упрощённое описание, но в целом адекватное. Так вот, очень удобно и в случае с моим Turion'ом работало всё это замечательно.

    А вот Atom повёл себя существенно хуже. Естественно, я попытался, проделать с ним тот же самый фокус и с ним. Но Atom начал греться даже в самом малопроизводительном P-состоянии. А потом ещё знакомый появился со своим Dothan'ом, с которым тоже этот conservative-фокус не сработал. Ноутбук перегревался и вырубался.

    5. Давайте будем throttle'ить.

    Но, не будем отчаиваться, и вспомним, что у процессоров есть ещё одна крутилка — T-состояния. И крутить этой крутилкой можно через так называемый limit-интерфейс. Штука это хоть и страшно называется, является очень простой по смыслу: можно ограничить минимальные по номеру, то есть, максимальные по производительности P и T состояния. Если посмотреть так:

    (это уже другой процессор, T2050)

    то можно увидеть, что эти самые ограничения. active — это текущий, user — это установленный со стороны операционной системы, а thermal — это тот, который должен устанавливать BIOS или аппаратура при обнаружении перегрева.

    Если через этот limit-интерфейс установить ограничения на T-состояния то процессор впадёт в throttle'инг и начнёт существенно меньше греться. В коде выше у меня процессор находится по причине своего безделья в состоянии T6, и это означает что он работает только на каждый 4-тый такт.

    6. ОК. Всё вместе или конфиг для cpufreqd.

    Собственно вот. Всё просто. Логика этого конфигурационного файла такова.

    A. cpureqd опрашивает состояние системы каждые 0.5 секунды.

    B. Когда в системе обнаруживается низкая вычислительная активность, она переходит в наименее производительное P-состояние и в достаточно глубокий throttle'инг (вообще-то он фанатский тут выбран, комфортнее работать когда опрос происходит через каждые 0.25 секунд, а в состоянии idle процессор уходит в T4).

    С. В режиме нагрузки процессор управляется по политике conservative с минимальными ограничениями. И с немного подкрученными порогами для перехода по режиму производительности вверх и вниз. Вверх conservative пойдёт, когда в текущем состоянии загрузка процессора превысит 75%, а вниз, когда упадёт ниже 25%.

    D. Когда же температура поднимется выше 55 процентов (да-да, cpufreqd он странный) от максимальной, то это приведёт к выполнению профиля too_hot, который переведёт процессор в максимальный throttling и минимальное по производительности из P-состояний.

    Небольшой хитростью тут является использования условия cpu_interval в правилах. Нагрузкой idle считается нагрузка на CPU от 0 до 6.5 процентов за предыдущий интервал наблюдения. А basic нагрузкой — нагрузка от 75 до 100.

    Логика здесь такая. Если помните, то я написал, что cpufreqd в ходе своей работы анализирует набор своих правил и выставляет каждому оценку — насколько оно соответствует текущей ситуации. И если оценка у правила достаточно высока и превосходит все достаточно высокие оценки, то cpufreqd применяет соответствующий этому правилу профиль (профили, на самом деле, но не важно). Поэтому, когда cpufreqd видит, что загрузка процессора не попадает в интервалы [0, 6.25] или [75, 100], при нормальной температуре системы, он просто ничего не делает.

    Так вот. Нам же нужно переключаться из состояния basic в состояние idle и обратно. Когда процессор находится в состоянии basic из-за настроек conservative при загрузке меньше 25% он будет переводить процессор в более низкое (тут и далее по производительности) P-состояние, тем самым повышая загрузку процессора в процентном выражении текущими вычислениями — просто все задачи начинают выполняться медленней, следовательно, требуют больше процессорного времени, следовательно, процессор загружается сильнее.

    Но из самого низкого P-состояния процессор должен перепрыгнуть в состояние idle, когда он работает в 4 раза медленней, чем в самом низком P-состоянии. И прыгнуть он туда должен при достаточно низкой нагрузке. Я выбрал этот параметр равным 25 / 4, но на самом деле можно было бы
    выбрать любую цифру меньшую, скажем, 60 / 4, чтобы при прыжке в idle нагрузка на процессор не возросла настолько, чтобы сработало правило basic, которое должно срабатывать при высокой загрузке (больше 75%) в состоянии idle. При этом 60 / 4 всё ещё меньше 25, поэтому режим idle не включится при работе под управляющим conservative, который при обнаружении загрузки процессора меньше 25 переключит его в более низкий P-режим, чем повысит нагрузку на процессор. И, поэтому, состояние idle не будет включаться, пока нагрузка на процессор не начнёт падать в самом низком P-режиме. ЧТД.

    Вот. Всё достаточно просто. Напоследок напишу, что параметры 0.5, 0:6 и 6.25 — фанатские, и могут быть не комфортными при работе в KDE или GNOME, изменение режимов работы системы раз в .5 секунды заметно для пользователя. Лучше поэтому использовать значения 0.25, 0:4, 12.5 соответственно. Кроме этого, естественно, вам придётся самостоятельно последить за температурой вашей системы и выставить комфортные именно для вас температурные интервалы. Тут только следует помнить, что тепловых зон в компьютере много, а в той форме, в которой в конфигурации выше используется критерий acpi_temperature температура берётся средней по всем этим зонам. Вообще, cpufreqd позволяет указывать конкретную температурную зону для наблюдения, и можно попробовать указать термозону процессора, но пока эта фича скорее похожа на баг :) там есть ошибки в коде. А понаблюдать за изменением температуры в термозонах можно при помощи команды $ watch cat /proc/acpi/thermal_zone/*/temperature

    Что может быть не так с настройками питания компонентов компьютера?

    Давайте сначала взглянем вот на эту диаграмму:

    реклама


    Очевидно, что ноутбуков продается гораздо больше, чем собирается настольных компьютеров и производители компонентов и софта во многом ориентируются на ноутбучный сегмент.
    В ноутбуках одна из ключевых характеристик - время автономной работы от батареи. Чтобы его продлить производители стараются максимально оптимизировать потребление энергии, снижая его всегда, когда это возможно. В качестве побочного эффекта мы получаем, что энергосбережение пытается взять власть и в моменты, когда ноутбук подключен в сеть и даже на настольном компьютере. Как только система чувствует, что нагрузка снижена или она бездействует, начинают активироваться режимы пониженного энергопотребления. И вот эти режимы могут на настольном компьютере неожиданно приводить к полному зависанию, отключению отдельного устройства или системы в целом.

    MSI RTX 3070 сливают дешевле любой другой, это за копейки Дешевая 3070 Gigabyte Gaming - успей пока не началось

    За последние 8 лет я сталкивался с таким несколько раз на настольных компьютерах. Обнаруженные проблемы можно разложить по следующим категориям:

    1. Внезапное отключение системы из-за высокого уровня c-states процессора
    2. Подвисания системы из-за высокого уровня с-states
    3. Внезапный отвал NVMe диска из-за режима энергопотребления по умолчанию, даже если диск был под нагрузкой
    4. Кратковременное снижение производительности NVMe дисков из-за режима энергопотребления по умолчанию, даже если диск был под нагрузкой.

    Проблемы у меня были с разными компонентами разных поколений и производителей: Intel i7-4770k, Ryzen-3900x, NVMe Kingston A2000. Судя по информации от других пользователей, проблемы бывают и со многими другими устройствами.

    реклама

    var firedYa28 = false; window.addEventListener('load', () => < if(navigator.userAgent.indexOf("Chrome-Lighthouse") < window.yaContextCb.push(()=>< Ya.Context.AdvManager.render(< renderTo: 'yandex_rtb_R-A-630193-28', blockId: 'R-A-630193-28' >) >) >, 3000); > > >);


    Первый раз я столкнулся с этим, когда 7 лет назад новенький компьютер с 4770k на борту начал подтормаживать без какой-либо серьезной нагрузки. Когда внезапно компьютер вырубился, я перебрал и перепроверил все компоненты: от блока питания до материнки. Путем исключения выяснил, что проблема с процессором, и, сначала уже хотел сдавать его по гарантии, но потом выяснил, что он исправен. Под Windows было крайне сложно понять что же происходит. Помог запуск под Linux и изучение его журнала, который оказался очень подробным. Система не вырубалась, но в списке ошибок было что почитать. Гуглю эти ошибки - и я узнаю, что ещё много людей мучаются с такой проблемой. Так я узнал про c-states и, что неким образом при его высоких значениях система сначала пытается снизить энергопотребление, а этого не хватает мощному десктопному процессору даже для простоя. Аналогичная ситуация происходила с Ryzen 3900х. Тоже хотел сдавать по гарантии, думал что два раза в одну воронку снаряд не попадает. Да и за 6 лет индустрия должна была (нет) уже с этим разобраться. Усложнялось все ещё тем, что если в случае с 4770k падения и подвисания происходили достаточно часто - раз в несколько дней и можно было отследить, то 3900х падал раз в месяц, да еще и был в офисе. Но, попробовав изменить c-states, все решилось и работает уже полтора года как часы.

    Похожая ситуация была с ssd дисками - их режимы ожидания что под Windows что под Linux похоже целиком пришли из ноутбучного мира, что не совсем дружит с десктопом.

    Что такое с-states, какие могут быть проблемы?


    реклама

    С-states - это режимы энергосбережения процессора. Впервые их ввели еще на 486м Intel'е.
    В большинстве систем есть 7 уровней C-states (плюс еще некоторые подуровни для определенных процессоров). В некоторых системах есть и 10 уровней. В других есть пропущенные уровни. Если активирован уровень C0, то все компоненты процессора потребляют энергию. Процессор в полностью рабочем состоянии и никаких проблем не возникает. Уровни C1-C2 соответствуют все еще включенному процессору с рабочим кэшом, но с остановкой либо замедлением одного или нескольких внутренних тактовых генераторов. Начиная с уровня C3 начинается спящий режим, кэш L1 инструкций пустой. Уровни С4-С6 определяют глубину этого спящего режима. Система, отслеживая свою активность, вычисляет на какой уровень c-state надо перейти в данный момент. Если активность снижается, система повышает уровень, снижая энергопотребление.

    У операционной системы есть глобальный параметр max_c-state, определяющий максимальное значение c-state в которое может уходить система. По умолчанию он как раз, наследуя ноутбучные правила, близок или равняется C6.

    Проблемы могут возникнуть с повышением уровня C-states. Выходя с C0 на С1/C2 может произойти отключение или подвисания там, где этого не ждешь. Объясняется это тем, что современные алгоритмы управления C-states писались практически одинаковыми как для ноутбуков так и для мощных десктопных процессоров. Казалось бы, если установлен максимальный уровень на C3 или больше - то уже без разницы, какой будет конкретно уровень - ведь проблемы начинаются, когда система еще не в спящем режиме, а раньше. Но это не всегда так, у Windows 7 были проблемы как раз когда с C3 повышали максимальный допустимый уровень до C6. Видимо в системе были разные алгоритмы работы с энергопотреблением для разных максимальных уровней энергопотребления, а не только для текущего уровня.

    Устраняем проблемы c С-states на Windows

    Чтобы устранить проблему с c-states надо понизить его максимальный допустимый уровень до такого, когда система начнет работать стабильно. Если вы (как я) не выключаете компьютер месяцами, то можете сразу выставить C0.

    Для этого надо под администратором воспользоваться утилитой командной строки POWERCFG :

    1. Узнаем доступные схемы питания c помощью powercfg /list:
    2. Выбираем схему Высокая производительность и копируем ее идентификатор. В моем случае идентификатор: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
    3. Выполняем команду powercfg /SETACVALUEINDEX 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c SUB_PROCESSOR IDLESTATEMAX 0:Где последняя цифра - максимальный допустимый уровень с-states, который вы хотите задать. В моем случае это 0. Эта команда меняет схему питания "Высокая производительность", задавая новый максимальный уровень для неё.
    4. Активируем схему питания: powercfg /SETACTIVE 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

    Устраняем проблемы с C-states на Linux:

    1. открываем под sudo файл /etc/default/grub
    2. ищем секцию GRUB_CMDLINE_LINUX_DEFAULT
    3. прописываем intel_idle.max_cstate=0, где цифра - максимальный допустимый уровень c-state
    4. не смущаемся, что параметр называется intel_idle, для AMD он тоже работает

    реклама

    Примечание: некоторые BIOS позволяют установить max c-state в своем меню, но не факт, что система не переопределит это значение.

    Проблемы с энергосбережением nvme дисков

    По аналогии с процессорами NVMe диски имеют несколько уровней энергосбережения.
    Данная технология называется Autonomous Power State Transition (APST) и призвана в первую очередь увеличить время работы батареи ноутбука.


    Контроллер собирает информацию об активности системы и частоте запросов к диску и выставляет оптимальный с его точки зрения режим энергопотребления. Работа этого алгоритма регулируется выбранной схемой энергопотребления, которая в первую очередь характеризуется величиной таймаута. Если за время более чем таймаут, указанный в схеме к накопителю не было ни одного запроса, то драйвер повышает глубину уровня ожидания NVMe, выходя из уровня S0. На более глубоких уровнях увеличивается максимальное время отклика диска. В настройках этой схемы, в целом беспроблемно работающей на ноутбуках может быть заложено состояние, зайдя в которое десктопная система вызовет сбой и диск отмонтируется из файловой системы. Более того, если ОС загружена с этого диска, то с большой вероятностью она умрёт, а испуганный пользователь захочет сдать диск или все остальные девайсы по гарантии. У меня отвал диска с системой был только под Линуксом, но сам этот диск отваливался и из под Windows (Windows была на SATA). Основная проблема была конечно не отвал, а подвисания.
    Ниже приведены стандартные настройки таймаутов NVMe для разных схем питания под Windows:


    Я не нашел, что такие схемы различаются для десктопов и ноутбуков. Но, к счастью, пользователь может управлять этой схемой. Если мы повысим таймаут, то диск просто никогда не успеет уйти на более глубокий уровень ожидания и будет всегда активен.

    Меняем схему энергосбережения NVMe под Windows 10

    1. Открываем реестр
    2. Проходим в раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\0012ee47-9041-4b5d-9b77-535fba8b1442\d639518a-e56d-4345-8af2-b9f32fb26109:
    3. Меняем значение в поле Attributes c 1 на 0:
    4. Теперь у нас доступна опция регулировки таймаута в настройках электропитания
    5. Win+X -> Управление электропитанием -> Дополнительные параметры питания -> Настройка схемы электропитания (для вашей текущей схемы) -> Изменить дополнительные параметры питания
    6. В открывшемся окне меняем таймаут на больший, если мы хотим, чтобы накопитель был активен почти всегда, и его не вырубало (я поставил 1000 когда были проблемы и они исчезли):

    Меняем схему энергосбережения на Linux:

    1. Открываем /etc/default/grub под sudo
    2. под секцией GRUB_CMDLINE_LINUX_DEFAULT прописываем nvme_core.default_ps_max_latency_us=0

    Как альтернатива - можно полностью отключить APST, но мне не удалось найти параметр.

    Заключение:

    Судя по тому, что я несколько раз сталкивался с этой проблемой и находил довольно многих пользователей с такими же неполадками, есть значительная часть десктопных компонентов отнесенная в сервис или сданная назад, будучи вполне рабочими, но не вполне совместимыми. Все это софтовые проблемы из-за ноутбучного влияния в коде ОС. Для рядового пользователя они совсем не приятные, и я надеюсь, что данный материал поможет кому-то из читателей.

    Как я могу установить Intel Idle Max Cstate на 1 и как я могу проверить, когда это будет сделано. У меня проблема с заморозкой из-за ядра следа залива.

    Я попробовал ядро ​​4.5 4.1.12 4.4, но проблема замораживания все еще продолжается. на данный момент 4.4 - это моя версия ядра.

    На данный момент (8/2019) этот поток фактически не утверждает, что установка intel_idle.max_cstate = 1 является официальным решением для ошибки, опубликованной в 2011 году. Так как в моем случае это (пришлось дублировать) периодически возникающая проблема, до того как я ДОБАВЬТЕ intel_idle.max_cstate = 1 к моему GRUB, я хотел бы получить некоторую документацию, подтверждающую это. Оригинальный документ Bugzilla неясен в этом отношении. Может ли какой-нибудь участник этого форума помочь мне официально подтвердить это «исправление»?

    При использовании GRUB:

    С помощью sudo редактируйте /etc/default/grub и редактируйте GRUB_CMDLINE_LINUX_DEFAULT строку, добавляя intel_idle.max_cstate=1 к тому, что уже может быть там. После сохранения файла запустите sudo update-grub , затем перезагрузите компьютер. Предложите сначала сохранить копию исходного файла grub.

    Чтобы проверить, что ваш cstate не идет глубже, чем 1, используйте турбостат (пакет: linux-tools-common).

    Пример (где что-то уже есть GRUB_CMDLINE_LINUX_DEFAULT ):

    Внесите изменения (используя мой метод для контроля конфигурации):

    Теперь проверьте (отредактировано):

    Интересно, какое значение в выводе turbostat показывает, что cstate не идет глубже, чем 1. Что вы имеете в виду deeper ? Что делать по-другому, если оно идет глубже? @Stephane: Под «глубже» я имел в виду более высокие состояния c, чем 1. Если вы правильно установили командную строку grub, она не должна переходить на cstate глубже (выше) 1. Вы можете наблюдать процессор и пакет, cstates больше чем 1 показывает 0,00% времени в этих состояниях на выходной линии турбостата. Мой Thinkpad X201i делал перезапуски каждый час. Я включил intel_idle.max_cstate=1 в grub, как GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1" при обновлении grub, sudo update-grub и перезапустил машину. Никаких перезапусков больше не происходит. Я рад, что решил свою проблему. Интересно, что именно это свойство говорит процессору, хотя

    Дополнительная информация: этот патч / скрипт получает режим энергосбережения. Приведенное выше решение для темы вообще убирает этот режим.

    Отредактируйте / etc / defaults / grub:

    Больше нет необходимости обновлять grub, если вы переключаетесь на самое последнее ядро.

    Согласно комментарию № 1013 в отчете об ошибках, это исправлено:

    Я давно не проверял эту ветку, но подумал, что должен опубликовать свои выводы на тот случай, если они кому-нибудь пригодятся.

    Низкоуровневый компьютер с процессором Intel N2807, который никогда не работал более 30 минут без сбоев, когда я не установил . max_cstates = 1, теперь прекрасно работает со стандартным ядром версии 5.3.1 или 4.19.75. Я запускал его в течение нескольких дней с каждой версией без каких-либо проблем. Среднее энергопотребление также снизилось чуть более чем на 10%.

    Исправление этой ошибки заняло около четырех лет, о чем впервые было сообщено 8 декабря 2015 года.

    Читайте также: