C states control что это

Обновлено: 07.07.2024

Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.

Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и наслаждается полученным результатом. Но вскоре он понимает, что для того, чтобы управлять менюшкой, хорошо бы знать закрыто оно сейчас или нет. Мы-то с вами тут программисты опытные, все понимаем, что нужно добавить флаг. Не вопрос, флаг есть.


Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:


Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:


Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния. О них дальше и пойдет речь.

Знакомьтесь, это Вася.




Состояние

Вася уже начинает понимать, что многие комбинации флагов не имеют смысла, а остальные можно легко описать парой слов, например: Disabled, Idle, Animating, Opened. Все мы тут программисты опытные, сразу вспоминаем про state machines. Но, для Васи придется рассказать что это и зачем. Простым языком, без всяких математических терминов.

У нас есть объект, например, вышеупомянутая менюшка. Объект всегда находится в каком-то одном состоянии и реагируя на различные события может между этими состояниями переходить. Обычно состояния, события и переходы удобно описывать вот такими схемами (кружочками обозначены начальное и конечные состояния):

Из схемы понятно, что из состояния Inactive в Active можно попасть только по событию Begin, а из состояния Paused можно попасть как и в Active, так и в Inactive. Такую простую концепцию почему-то называют «Конечный Автомат» или «Finite State Machine», что очень пугает обычных людей.

По завету ООП, состояния должны быть скрыты внутри объекта и просто так снаружи не доступны. Например, у объекта во время работы может быть 20 разных состояний, но внешнее API на вопрос «чо как дела?» отвечает «ничо так» на 19 из них и только на 1 ругается матом, что проср*ли все полимеры.

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


Самая простая в мире стейт машина

А вот так обрабатывает события в зависимости от текущего состояния:

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

State Pattern

Погуглив пару часов, Вася решает, что State Pattern идеально подходит в данной ситуации. Тем более, что старшие программисты все время соревнуются кто больше паттернов запихнет в свой апп, так что, решает Вася, паттерны это дело важное.

Например, для State Pattern можно сделать интерфейс IState:

И по отдельному классу для каждого состояния, которые этот интерфейс имплементят. В теории выглядит красиво и 100% по учебнику.

Но, во-первых, для каждой несчастной мелкой стейт машины нужно городить уйму классов, что само по себе небыстро. Во-вторых, рано или поздно начнутся проблемы с доступом к общим данным. Где их хранить? В основном классе? А как классы-состояния получат к ним доступ? А как мне тут за 15 минут перед дедлайном впилить быстро мелкий хак в обход правил? И подобные проблемы взаимодействия, которые будут сильно тормозить разработку.

Реализация на основе особенностей языка
  1. наследуемся от класса FiniteStateMachine,
  2. создаем методы с названием stateName_eventName(), которые автоматически вызываются при переходе по состояниям и при обработке событий

Реализовав систему описанную выше, Вася понимает, что у нее тоже больше минусов, чем плюсов:

  • Нужно наследоваться от класса FiniteStateMachine,
  • В реакциях на кастомные события также нужно писать большие switch конструкции,
  • Нет возможности передать параметры при изменении состояния.
Фреймворк

А тем временем, Вася уже вовсю стал вникать в теорию стейт машин и решил, что хорошо бы иметь возможность формально их описывать через API или (о Боже) через XML, что в теории звучит круто. Мы-то с вами тут программисты опытные, все понимаем, что нужно писать свой фреймворк. Потому что другие не подходят, так как у всех у них есть один фатальный недостаток.

Вася решил, что с помощью его фреймворка можно будет быстро и легко создать стейт машину без необходимости писать много ненужного кода. Фреймворк не будет накладывать никаких ограничений на разработчика. Все вокруг будут веселы и жизнерадостны.

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

Вот, например, описание конечного автомата фреймворком stateless:

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

XML — это отдельное зло. Кто-то когда-то придумал использовать его для написания конфигов. Стадо леммингов java разработчиков длительное время молилось на него. А теперь никто уже и не знает зачем все используют XML, но продолжают бить всех, кто пытается от него избавиться.

Вася тоже загорелся идеей, что можно все сконфигурировать в XML и НЕ ПИСАТЬ НИ СТРОЧКИ КОДА! В итоге в его фреймворке отдельно лежат XML файлы примерно такого содержания:

Класс! И никакого программирования. Но, мы-то с вами тут программисты опытные, все понимаем, что программирование никуда не ушло. Вася заменил кусок императивного кода на кусок декларативного кода, добавив при этом во фреймворк интерпретатор XML, который все еще в пару раз усложнил. А потом попробуй это отдебажить, когда код на разных языках и разбросан по проекту.

Соглашение

И тут Васе все это надоело и он вернулся обратно к самому простому в мире конечному автомату. Он его немного переделал и придумал правила как писать в нем код.

UPDATE: спасибо за комментарии. Здесь действительно не хватало небольшого объяснения.

У нас есть несколько состояний. Переход между ними — это транзакция из атомарных операций, то есть они все происходят всегда вместе, в правильном порядке и между ними не может вклиниться еще какой-то код. При смене состояния с A на B происходит следующее: выполняется код выхода из состояния A, состояние меняется с A на B, выполняется код входа в состояние B.

Для перехода на состояние A нужно вызвать метод stateA, который выполнит нужную логику и вызовет setState(A). Самому вызывать setState(A) крайне не рекомендуется.


UPDATE: В setState() пишется уникальная логика выхода из состояния, а в stateB() возможна специфическая логика выхода из состояния A при переходе в B. Но очень редко используется.

Простое соглашение для написания стейт машин. Оно достаточно гибкое и имеет следующие плюсы:

  • почти вся логика при смене состояний находится в методах stateA(), что позволяет разбить гигантский switch в setState() и сделать код более читаемым,
  • смена состояния происходит только через методы stateA(), что облегчает отладку,
  • новому состоянию легко можно передавать параметры, например, если у книги есть состояние Page, то перейти на новую страницу можно просто сменив состояния вызвав statePage(42)
  • в обработчиках событий всегда понятно какая логика выполняется в каких состояниях,
  • все члены команды знают где писать логику для входа и выхода из состояния,
  • нет необходимости в каком-то фреймворке и предварительной конфигурации конечного автомата,
  • есть возможность грязно все похачить в последний момент, если уж совсем подругому никак.

Как и во всех соглашениях, какой-то код может сперва находиться в одном месте, но потом у него появится другой смысл, или окажется, что он где-то дублируется. Тогда мы можем его перенести в другое место. Никто нам не запрещает. Все-таки код не вытесан из камня, это всего лишь текст, который (о ужас!) можно и нужно менять с развитием проекта.

UPDATE: а setState() вполне можно заменить одним сеттером для наглядности.

Заключение

На этом заканчивается увлекательное приключение Васи в мире стейт машин. А ведь впереди еще столько всего интересного. Отдельного топика бы только заслужили параллельные и зависимые стейт машины.

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

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

Регулировка частоты из под Windows

Включенная опция Global C-State Control позволяет регулировать частоту проца из под Windows. Можно опустить частоту до минимума, регулируя в процентах. Открыть настройку можно зайдя в панель управления, выбрав значок Электропитание:




Как снизить энергопотребление процессора во время его работы?

На процессорах для массового использования (мы не берем в расчет вещи, которые возможны при их проектировании) для снижения потребляемой энергии можно реализовать один из сценариев:

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

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


Примечание для тех, кто разбирается в цифровой электронике: Pcpu = Pdynamic + Pshort circuit + Pleak. При работающем процессоре Pdynamic является наиболее важной составляющей, именно эта часть зависит линейно от частоты и квадратично от напряжения. Pshort circuit пропорционально частоте, а Pleak — напряжению.

Более того, напряжение и тактовая частота связаны линейной зависимостью.

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

Применима ли эта информация о C-состояниях и P-состояниях к мобильным и встраиваемым процессорам?

Для примера, недавний MacBook Air с процессором i5-5350U в основном поддерживает возможности, описанные выше (но я не уверен про P-состояния, контролируемые оборудованием). Я также смотрел документацию ARM Cortex-A, и, хотя там применяются другие термины, механизмы управления питанием выглядят похоже.

Особенности CPU

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

  • состояния простоя (Idle States);
  • усовершенствованная технология Intel® SpeedStep (Enhanced Intel® SpeedStep Technology).

Теперь выясним, что значит каждое из этих определений.

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

Итак, я нашел информационную картинку-описание некоторых режимов работы процессора, смотрим (картинка правда большая, но зато инфа полезная):


P-состояния, управляемые оборудованием

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

Я хочу рассказать об этом подробнее в следующей статье, но сейчас я поделюсь с вами своими мыслями. Мой домашний компьютер работает в этом режиме, я узнал это, проверив IA32_PM_ENABLE. Максимальный (но не гарантированный) уровень производительности — 39, минимальный — 1. Можно предположить, что существует 39 P-состояний. На данный момент уровень 39 установлен ОС как минимальный и как максимальный, потому что я отключил динамическое изменение частоты процессора в ядре.

Каков предел энергопотребления процессора?

Это во многом зависит от процессора, но для процессора E3-1245 v5 @ 3.50 ГГц расчетная тепловая мощность (Thermal Design Power, TDP) составляет 80 ватт. Это среднее значение, которое процессор может выдерживать бесконечно долго (Power Limit, PL1 на изображении ниже). Системы охлаждения должны быть рассчитаны на это значение, чтобы быть надежными. Фактическое энергопотребление процессора может быть выше в течение короткого промежутка времени (состояния PL2, PL3, PL4 на изображении ниже). TDP измеряется при нагрузке высокой вычислительной сложности (худший случай), когда все ядра работают на базовой частоте (3.5 ГГц).


Как видно на изображении выше, процессор в состоянии PL2 потребляет больше энергии, чем заявлено в TDP. Процессор может находиться в этом состоянии до 100 секунд, а это достаточно долго.

Что вынуждает ядро входить в определенное С-состояние?

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

Как я могу узнать состояние процессора?

Существует не так много приложений, которые могут выводить эту информацию. Но вы можете использовать, например, CoreFreq.

Сразу короткий ответ: опция активирует поддержку энергосберегательных режимов процессора.


В биосе ASRock UEFI эта опция находится как видите в разделе Advanced\CPU Configuration.

Как программно запросить переход в энергосберегающее С-состояние?

Современный (но не единственный) способ запросить переход в энергосберегающее состояние — это использовать инструкцию MWAIT или инструкцию HLT. Это инструкции привилегированного уровня, и они не могут быть выполнены пользовательскими программами.

Инструкция MWAIT (Monitor Wait) заставляет процессор перейти в оптимизированное состояние (C-состояние) до тех пор, пока по указанному (с помощью другой инструкции, MONITOR) адресу не будет произведена запись. Для управления питанием MWAIT работает с регистром EAX. Биты 4-7 используются для указания целевого С-состояния, а биты 0-3 указывают суб-состояние.

Примечание: Я думаю, что на данный момент только AMD обладает инструкциями MONITORX/MWAITX, которые, помимо мониторинга записи по адресу, работают с таймером. Это еще называется Timed MWAIT.

Инструкция HLT (halt) останавливает выполнение, и ядро переходит в состояние HALT до тех пор, пока не произойдет прерывание. Это означает, что ядро переходит в состояние C1 или C1E.

С-состояния

Вот базовые С-состояния (определенные в стандарте ACPI).

  • C0: Active, процессор/ядро выполняет инструкции. Здесь применяются P-состояния, процессор/ядро могут работать в режиме максимальной производительности (P0) или в режиме энергосбережения (в состоянии, отличном от P0).
  • C1: Halt, процессор не выполняет инструкций, но может мгновенно вернуться в состояние С0. Поскольку процессор не работает, то P-состояния не актуальны для состояний, отличных от С0.
  • C2: Stop-Clock, схож с C1, но требует больше времени для возврата в C0.
  • С3: Sleep. Возврат в C0 требует ощутимо большего времени.

Примечание: Из-за технологии Intel® Hyper-Threading существуют также С-состояния потоков. Хотя отдельный поток может работать с С-состояниями, изменения в энергопотреблении происходят, только когда ядро входит в нужное состояние. В данной статье тема C-состояний на потоках рассматриваться не будет.

Вот описание состояний из даташита:


Примечание: LLC обозначает Last Level Cache, кэш последнего уровня и обозначает общий L3 кэш процессора.

Визуальное представление состояний:


Источник: Software Impact to Platform Energy-Efficiency White Paper

Последовательность C-состояний простыми словами:

  • Нормальная работа при C0.
  • Сначала останавливается тактовый генератор простаивающего ядра (С1).
  • Затем локальные кэши ядра (L1/L2) сбрасываются и снимается напряжение с ядра (С3).
  • Как только все ядра отключены, общий кэш (L3/LLC) ядер сбрасывается и процессор (почти) полностью может быть обесточен. Я говорю «почти», потому что, по моим предположениям, какая-то часть должна быть активна, чтобы вернуть процессор в состояние С0.


Однако если ядро работает (C0), то единственное состояние, в котором может находиться процессор, — C0. С другой стороны, если ядро полностью выключено (C8), процессор может находиться в C0, если другое ядро работает.

Примечание: Intel Software Developer’s Manual упоминает про суб-C-состояния (sub C-state). Каждое С-состояние состоит из нескольких суб-С-состояний. После изучения исходного кода модуля ядра intel_idle я понял, что состояния C1 и C1E являются состоянием С1 с подтипом 0 и 1 соответственно.

Число подтипов для каждого из восьми С-состояний (0..7) определяется с помощью инструкции CPUID. Для моего процессора утилита cpuid выводит следующую информацию:

Я создал гистограмму, представленную ниже, из исходного кода драйвера intel_idle для моего процессора (модель 0x5e). Подписи горизонтальной оси:

Имя C-состояния: специфичное для процессора состояние: специфичное суб-состояние.

Вертикальная ось обозначает задержку выхода и целевые резидентные значения из исходного кода. Задержка выхода используется для оценки влияния данного состояния в реальном времени (то есть сколько времени потребуется для возвращения в С0 из этого состояния). Целевое резидентное значение обозначает минимальное время, которое ядро должно находиться в данном состоянии, чтобы оправдать энергетические затраты на переход в это состояние и обратно. Обратите внимание на логарифмический масштаб вертикальной оси. Задержки и минимальное время нахождения в состоянии увеличивается экспоненциально с увеличением номера состояния.


Константы задержок выхода и целевых резидентных значении C-состояний в исходном коде intel_idle
Примечание: Хотя состояния С9 и С10 включены в таблицу, они имеют 0 суб-состояний и поэтому не используются в моем процессоре. Остальные процессоры из семейства могут поддерживать эти состояния.

Как это все работает, например, на Linux?

На этот вопрос я отвечу в другой статье.

Возможно ли отключить С-состояния (всегда использовать С0)?

Это возможно, но не рекомендуется. В даташите (секция 4.2.2, страница 64) есть примечание: «Долгосрочная надежность не гарантируется, если все энергосберегающие состояния простоя не включены». Поэтому вам не стоит отключать С-состояния.

P-состояния

P-состояния подразумевают, что ядро в состоянии С0, потому что ему требуется питание, чтобы выполнять инструкции. P-состояния позволяют изменять напряжение и частоту ядра (другими словами рабочий режим), чтобы снизить энергопотребление. Существует набор P-состояний, каждое из которых соответствует разных рабочим режимам (пары напряжение-частота). Наиболее высокий рабочий режим (P0) предоставляет максимальную производительность.

Процессор Intel® Xeon® E3–1200 v5 позволяет контролировать P-состояния из операционной системы (Intel® SpeedStep Technology) или оставить это оборудованию (Intel® Speed Shift Technology). Вся информация ниже специфична для семейства Intel® Xeon® E3-1200 v5, но я полагаю, это в той или иной степени актуально и для других современных процессоров.

Важные моменты

Функция в биосе ASUS:


Дополнительная информация, которая может быть полезной:


Заметки про Intel® Turbo Boost

Поскольку TDP (расчетная тепловая мощность) — это максимальная мощность, которую процессор может выдержать, то процессор может повышать свою частоту выше базовой, при условии что энергопотребление не превысит TDP. Технология Turbo Boost может временно повышать энергопотребление до границы PL2 (Power Limit 2) на короткий промежуток времени. Поведение Turbo Boost может быть изменено через подсказки оборудованию.

Краткое руководство по управлению питанием процессора


Как центральный процессор может сокращать собственное энергопотребление? Основы этого процесса — в статье.

Центральный процессор (CPU) спроектирован на бесконечно долгую работу при определенной нагрузке. Практически никто не проводит вычисления круглые сутки, поэтому большую часть времени он не работает на расчетном максимуме. Тогда какой смысл держать его включенным на полную мощность? Здесь стоит задуматься об управлении питанием процессора. Эта тема включает в себя оперативную память, графические ускорители и так далее, но я собираюсь рассказать только про CPU.

Если вы знаете про C-состояния (C-states), P-состояния (P-states) и то, как процессор переходит между ними, то, возможно, в этой статье вы не увидите ничего нового. Если это не так, продолжайте читать.

Я планировал добавить реальные примеры из ОС Linux, но статья становилась все больше, так что я решил приберечь это для следующей статьи.

Основные источники информации, использованные в этом тексте:

Заключение

Надеюсь эта информация была полезной. Удачи и добра, до новых встреч друзья! и берегите себя!

Функция энергосбережения процессоров Ryzen. При активации проц будет скидывать частоту в простое, в результате меньше потребляет энергии и меньше нагрев.

Состояния питания ACPI

Прежде чем говорить про P-состояния, стоит упомянуть про состояния питания ACPI. Это то, что мы, пользователи, знаем, когда используем компьютер. Так называемые глобальные системные состояния (G[Х]) перечислены в таблице ниже.


Источник: ACPI Specification v6.2
Также существует специальное глобальное состояние G1/S4, Non-Volatile Sleep, когда состояние системы сохраняется на энергонезависимое хранилище (например, диск) и затем производится выключение. Это позволяет достичь минимального энергопотребления, как в состоянии Soft Off, но возвращение в состояние G0 возможно без перезагрузки. Оно более известно как гибернация.

Существует несколько состояний сна (Sx). Всего таких состояний шесть, включая S0 — отсутствие сна. Состояния S1-S4 используются в G1, а S5, Soft Off, используется в G2. Краткий обзор:

  • G0/S0: Компьютер работает, не спит.
  • G1: Sleeping.
    • G1/S1: Power on Suspend. Состояние системы сохраняется, питание процессора и кэшей поддерживается.
    • G1/S2: Процессор отключен, кэши сброшены.
    • G1/S3: Standby или Suspend to RAM (STR). Оперативная память остается практически единственным компонентом с питанием.
    • G1/S4: Hibernation или Suspend to Disk. Все сохраняется в энергонезависимую память, все системы обесточиваются.


    Вот поддерживаемые состояния ACPI.


    Состояния питания (C-states) vs состояния производительности (P-states)

    Состояния питания (C-states) vs состояния производительности (P-states)
    Вот два способа снизить энергопотребление процессора:

    • отключить некоторые подсистемы;
    • снизить напряжение/частоту.

    P-состояния описывают второй случай. Подсистемы процессора работают, но не требуют максимальной производительности, поэтому напряжение и/или тактовая частота для этой подсистемы может быть снижена. Таким образом, P-состояния, P[X], обозначают, что некоторая подсистема (например, ядро), работает на заданной паре (частота, напряжение).

    Так как большинство современных процессоров состоит из нескольких ядер, то С-состояния разделены на С-состояния ядра (Core C-states, CC-states) и на С-состояния процессора (Package C-states, PC-states). Причина появления PC-состояний очень проста. Существуют компоненты с общим доступом (например, общий кэш), которые могут быть отключены только после отключения всех ядер, имеющих доступ к этому компоненту. Однако мы в роли пользователя или программиста не можем взаимодействовать с состояниями пакета напрямую, но можем управлять состояниями отдельных ядер. Таким образом, управляя CC-состояниями, мы косвенно управляем и PC-состояниями.

    Состояния нумеруются от нуля по возрастанию, то есть C0, C1… и P0, P1… Большее число обозначает большее энергосбережение. C0 означает, что все компоненты включены. P0 означает максимальную производительность, то есть максимальные тактовую частоту, напряжение и энергопотребление.

    P-состояния, управляемые операционной системой

    В этом случае операционная система знает о P-состояниях и конкретном состоянии, запрошенным ОС. Проще говоря, операционная система выбирает рабочую частоту, а напряжение подбирается процессором в зависимости от частоты и других факторов. После того, как P-состояние запрошено записью в моделезависимый регистр (подразумевается запись 16 бит в регистр IA32_PERF_CTL), напряжение изменяется до автоматически вычисленного значения и тактовый генератор переключается на заданную частоту. Все ядра имеют одно общее P-состояние, поэтому невозможно установить P-состояние эксклюзивно для одного ядра. Текущее P-состояние (рабочий режим) можно узнать, прочитав информацию из другого моделезависимого регистра — IA32_PERF_STATUS.

    Смена P-состояния мгновенна, поэтому в секунду можно выполнять множество переходов. Это отличает от переходов C, которые выполняются дольше и требуют энергетических затрат.

    Заключение

    Добавить комментарий Отменить ответ

    Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

    Как прерывания влияют на процессор\ядро в состоянии сна?

    Когда происходит прерывание, соответствующее ядро пробуждается и переходит в состояние С0. Однако, например Intel® Xeon® E3-1200 v5, поддерживает технологию Power Aware Interrupt Routing (PAIR), у которой есть два достоинства:

    • для энергосбережения прерывание может быть переадресовано работающему ядру, чтобы не будить спящее ядро;
    • для производительности прерывание может быть переадресовано от работающего на полную мощность ядра к простаивающему (С1) ядру.

    Комбинации состояний ACPI G/S и С-состояний процессора

    Приятно видеть все комбинации в таблице:


    В состоянии G0/S0/C8 системы процессора запущены, но все ядра отключены.

    В G1 (S3 или S4) некорректно говорить про С-состояния (это касается как CC-состояний, так и PC-состояний), так как процессор полностью обесточен.

    Для G3 не существует S-состояний. Система не спит, она физически отключена и не может проснуться. Ей необходимо сначала получить питание.

    Энергосберегающие режимы на практике

    Важно понимать, что все это может не работать. Почему? Из-за настроек электропитания Windows, в которых может в минимальном/максимальном состоянии процессора стоять 100%. Тогда проц будет постоянно работать на максимальной частоте. Открыть данные настройки можно так: Панель управления > значок Электропитание > напротив активной схемы нажимаем настройка > изменить дополнительные параметры > в самом низу раскрываем пункт Управление питанием процессора.

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