LINUX.ORG.RU

Выпуск Intel Low Power Mode Daemon версии 0.0.4

 ,

Выпуск Intel Low Power Mode Daemon версии 0.0.4

2

2

12 июня инженерами Intel был выпущен Intel Low Power Mode Daemon версии 0.0.4 с «LPMD» — демон с открытым исходным кодом для оптимизации активного энергопотребления в режиме ожидания для современных гибридных процессоров Core под Linux, которые имеют комбинацию ядер E и P.

Intel LPMD выбирает наиболее энергоэффективные процессоры на основе обнаруженной топологии процессора или файла пользовательской конфигурации. Затем, основываясь на использовании системы и других подсказках, он переводит систему в режим пониженного энергопотребления, когда это применимо, задействуя наиболее энергоэффективные ядра ЦП и отключая ядра с более высокой мощностью/производительностью, когда они не нужны. LPMD до сих пор слабо распространён в основных дистрибутивах Linux и не был популярен среди пользователей Intel Linux по причине низкой скорости разработки.

Также в версии 0.0.4 усовершенствовано:

  • монитор интерфейса аппаратной обратной связи (HFI) для обработки последовательных подсказок в режиме низкого энергопотребления;
  • поддержка мониторинга HFI подсказок от запрещенных процессоров;
  • поддержка нескольких состояний пониженного энергопотребления;
  • поддержка подсказок по типам рабочей нагрузки;
  • поддержка изменения настроек энергоэффективности (EPP) при переходе в режим пониженного энергопотребления.

Благодаря поддержке нескольких состояний пониженного энергопотребления Intel LPMD может определять несколько состояний на основе настроек EPP/EPB/ITMT, миграции IRQ и миграции задач. Различные состояния низкого энергопотребления также могут быть выбраны на основе разных порогов использования.

>>> Загрузка демона и подробности на странице проекта в github

★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 5)

конфиги в xml и в зависимостях systemd у низкоуровневой утилитки. ынтерпрайс, чё...

hzk
()
Ответ на: комментарий от MEZON

Маловероятно, AMD во-первых не релизнула ещё E-P cores (C-cores немного про другое), во-вторых не имеет даже драйвера для CPPC (она прямо сейчас мержится), без него ОС даже не умеет понять топологию железных ядер.

whereisthelinus
()
Ответ на: комментарий от hzk

конфиги в xml

Давно удивляюсь, чем вызвано такое раздражение форматом XML? Поддержка XML обычно в разы лучше всяких разных JSON, Yaml и прочих модно-молодёжных форматов. В стандартном JSON, к тому же, ещё и комментарии запрещены.

zg
()
Ответ на: комментарий от greenman

Тут всплыла еще интересная штука релевантная и для интела и для амд

https://bugzilla.kernel.org/show_bug.cgi?id=218169

Получается что прерывания от железяк выводят из сна сразу несколько ядер. Причем как-то не сильно заботясь E ядро, P ядро. Амд это сейчас несколько более пофиг, но тоже готовят архитектуру с Е и P. Но в любом случае механизма разумно раскидывающего обработку аппаратны прерываний у линукса нет. И может возникнуть что нажатие клавиши и движение пальцем по тачпаду - функции ерундовые который под силу обработать одному E-ядру - выведут из глубокого С-стейта 3 P ядра.

Учитывая что совсем вот полный idle в жизни встречается редко - даже при чтении странички какой-то там скролл крутится периодически - этот эффект может существенно повлиять на практическую автономность устройства.

И в целом по топику - если бы можно было динамичеcки менять количество включенных ядер и вычислительных блоков GPU - профит очевиден. Ну вот для написания этого поста мне точно не надо 8 ядер 7840 райзена и вся мощь 780M. И по большому счету это мне потребуется процентах в 10 случаев - когда надо порендерить или покомпилировать.

Qui-Gon ★★★★★
()
Ответ на: комментарий от zg

если расшифровать yaml, то станет ясно что я имел в виду. а кто хранит конфиги для людей в json, тот сам себя наказал.

hzk
()
Последнее исправление: hzk (всего исправлений: 1)
Ответ на: комментарий от braboar

Ладно, согласен, что изначально это был Yet Another Markup Language.

Терминология не так важна. Мне просто интересно, откуда такая неприязнь к XML? Вот @hzk предложил посмотреть на значение аббревиатуры Yaml. Но, что по-новому, что по-старому, неприязнь к XML она не объясняет.

zg
()
Ответ на: комментарий от zg

Скорее причина в том, что XML заявлялся как ОКОНЧАТЕЛЬНЫЙ ответ на _все_ вопросы.

Включая, например, вопрос «В каком формате хранить человекочитаемые исходные тексты?» с подвопросом «В каком формате хранить математические формулы?» При этом, следует отметить за последовательность авторов разметки, давался пример разметки для решения квадратного уравнения из _25_ строчек XML-кода. С человекочитаемостью так же имеются весьма значимые проблемы. Я столкнулся с этим разбираясь с форматом DocBook, который я осилил, но желание с ним связываться в будущем у меня отбило напрочь. Sgml по сравнению заруливал своей простотой, хоть и был крайне ограничен.

И так по всем фронтам «Ответ на _все_ вопросы» уступает по любому из них специализированному решению.

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 2)
Ответ на: комментарий от Evgueni

Я правильно понимаю, что к xml ровно 2 претензии: низкая человекочитаемость и бОльшие накладные расходы (по сравнению с json)?

Или есть ещё что-то?

Harliff ★★★★★
()
Последнее исправление: Harliff (всего исправлений: 1)
Ответ на: комментарий от Evgueni

Скорее причина в том, что XML заявлялся как ОКОНЧАТЕЛЬНЫЙ ответ на все вопросы.

Не помню такого.

Включая, например, вопрос «В каком формате хранить человекочитаемые исходные тексты?»

XML всегда рассматривался как формат хранения данных, а не кода.

с подвопросом «В каком формате хранить математические формулы?»

Для формул всегда существовали свои форматы. XML хорош прежде всего для структурированных данных.

Sgml по сравнению заруливал своей простотой, хоть и был крайне ограничен.

SGML - это прародитель XML и HTML. XML является как раз таки его упрощённой версией.

zg
()
Ответ на: комментарий от Harliff

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

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 1)
Ответ на: комментарий от zg

Не помню такого.

А я помню.

XML всегда рассматривался как формат хранения данных, а не кода.

Это зависит от области применения понятия. Для меня разметка текста из которого должна получиться книга — это код. Но конечно можно цепляться и взывать к формальности.

Для формул всегда существовали свои форматы. XML хорош прежде всего для структурированных данных.

XML подавался как язык в котором удобно описывать формулы. Какое может быть доверие к технологии после подобных явно ложных утверждений?

SGML - это прародитель XML и HTML. XML является как раз таки его упрощённой версией.

Нет. Просто похож, как и куча подобных языков разметки.

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 1)

Пользуясь случаем, а как на 12 поколении интела энергосбережением\частотой рулить сейчас нужно? В автоматическом режиме, чтобы оно там все само как-нибудь. Ну т.е. обязательные конфиги, модули ядра, доп. утилиты? Е-ядер на данный момент нет, десктоп, так что задача сильно легче.

sehellion ★★★★★
()
Ответ на: комментарий от Qui-Gon

для написания этого поста мне точно не надо 8 ядер 7840 райзена и вся мощь 780M

У меня сейчас райзен 7840 от батарейки потребляет ~6ватт, а i5-1340P - ~5ватт. Уже хорошо. А можно сделать лучше?

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

rupert ★★★★★
()
Ответ на: комментарий от zg

XML создан не для людей. Точнее, не для нормальных людей, а для людей со странностями, которые любят постоянную зубную боль. Нормальные люди предпочитают конфиги в простых форматах, даже если они имеют определённые ограничения. JSON тоже для машин, поэтому там и нет комментариев. Лично я предпочитаю TOML.

rupert ★★★★★
()
Ответ на: комментарий от Harliff

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

Текстовый формат несёт очевидные издержки производительности, но по факту составить валидный xml с корректными неймспейсами может только ПО, вручную это делать очень сложно.

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

instant
()
Ответ на: комментарий от zg

Ну, веб это вообще отдельный случай, где одни слои говна накладываются на другие.

rupert ★★★★★
()
Ответ на: комментарий от zg

откуда такая неприязнь к XML?

Неприятно глазами читать конфиг. YAML тоже такое себе - у меня встроенного глазометра нет. INI - норм, хоть и слишком прост для сложных вещей. Что-то типа isc-dhcpd - ну, наверное да (я не предлагаю и упоротую логику создателей dhcpd брать, а только стиль конфига). JSON слегка полегче XML в глаза заходит. И полегче YAML, на мой взгляд.
Вот и всё.

BydymTydym
()
Ответ на: комментарий от Qui-Gon

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

cobold ★★★★★
()
Ответ на: комментарий от cobold

Ну скажем так - у меня проц через ryzenadj удушен на 8 ватт TDP, встройка - в режиме low. И этого за глаза на весь броузинг с кучей вкладок, почту, офисные программы.

Qui-Gon ★★★★★
()
Ответ на: комментарий от question4

Я позырил. Отличия от INI минимальные. Что-то подобное я «придумал» еще лет 20 назад для нескольких своих программ, только там еще и хеши были, а у разделов можно было иерархию явно указывать [Подаздел/раздел/поддомен/домен] В целом, для конфигов что-то такое - очевидная вещь, если не страдать избыточным прозелитизмом (конфиг на С или на SNOBOL - это крайние случаи такого, XML - чуть полегче, но из этой же оперы)

BydymTydym
()
Последнее исправление: BydymTydym (всего исправлений: 1)
Ответ на: комментарий от BydymTydym

Я позырил. Отличия от INI минимальные. Что-то подобное я «придумал» еще лет 20 назад для нескольких своих программ, только там еще и хеши были, а у разделов можно было иерархию явно указывать

Я работал с программой, которая в INI хранила таблицы в CSV.

question4 ★★★★★
()
Ответ на: комментарий от instant

никто никогда не составляет хмл файлы вручную.

соап и хмл удобен тем что в любом языке есть библиотеки стандартизировано с ними работающие.

маршалинг-демаршалинг руками делают только неумные

guyvernk
()
Ответ на: комментарий от guyvernk

никто никогда не составляет хмл файлы вручную.

Вообще-то это официальный формат Linux HOWTO, которые набираются вручную. Во времена sgml точно так и было, но DocBook это простое действо сделал сложнее.

O'Reilly рекомендовала xml (DocBook), как входной формат для их книг. Твёрдая копия правда через troff доводилась.

XML продавался, как формат удобный для набора человека руками. Но что-то пошло не так.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

Да нормально все пошло, весь enterprise, как сидел, так и сидит по большей части. Ничего лучше пока по факту не придумали. json - с его «полтора» типами и с кривущей json-schema это только для web и обычно обязательно, т.к. остальное веберами не воспринимается априоре, но им вообще все сложно, кроме перекрашивания кнопок. Вот с мобилками уже сложней, туда всеже пытаются какой-нибудь grpc или graphql в случае графов и асинхронности/подписок прикрутить.

Bsplesk
()
Ответ на: комментарий от Evgueni

Все перечисленная это капля в море.

В банках схемы данных/агрегатов/бизнес_области как были в xsd так и остались. Потому что из нее любой язык может нагенерить актуальные модели. Ущербный openapi и рядом не стоял ни с wsdl ни с xsd/xml.

Маршализация/демаршализация сложных моделей, со строгой типизацией и валидацией - это по мне суть xml. И внятной альтернативы ей не существует

guyvernk
()
Последнее исправление: guyvernk (всего исправлений: 2)

Я использовал ini в значениях которого можно писать JSON

Psilocybe ★★★★
()
Ответ на: комментарий от guyvernk

Я перечислил то, с чем _сам_ столкнулся и чего _сам_ наелся. Другие люди сталкиваются с другими сторонами этого явления и те, кто хоть немножко смотрит по сторонам (а не ограничен рамками «интерпрайза») восторгов по поводу данной технологии не выражают. Это просто ещё один язык (даже не язык, а так обёртка) с помощью которого программа может говорить с программой (тысячи их) и _живым_ людям сей выхлоп показывать совершенно не стоит — не поймутссс.

Evgueni ★★★★★
()
Ответ на: комментарий от Bsplesk

Ну если есть только то, что даёт «интерпрайз», ну тогда ладно. Вкус дерьма — и к нему привыкнуть можно.

Evgueni ★★★★★
()
Ответ на: комментарий от whereisthelinus

Ядра с 3д-кэшем, ядра без кэша, Ц-ядра. Чем не E-P?

MEZON ★★★★★
()
Ответ на: комментарий от guyvernk

ты вот говоришь

никто никогда не составляет хмл файлы вручную

руками делают только неумные

и пишешь это прямо в комментарии к тулзе, у которой конфиг в XML

https://github.com/intel/intel-lpmd/blob/v0.0.4/data/intel_lpmd_config.xml

https://github.com/intel/intel-lpmd/blob/v0.0.4/data/intel_lpmd_config_examples.xml

автоматизированную утилиту для формирования конфига я что-то там не вижу

выходит, и составляют руками, и нам советуют

P.S.

в любом языке есть библиотеки стандартизировано с ними работающие

в гите сабжа можно полюбоваться на применение библиотек, стандартизированно работающих с XML в сишном коде.

трудолюбивые программисты аж 455 строк нафигачили в lpmd_config.c, видимо настолько удобно

instant
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.