Мэтью Гаррет, известный разработчик ядра Linux и лауреат премии за вклад в развитие свободного ПО, опубликовал (http://mjg59.dreamwidth.org/34868.html) результаты эксперимента по задействованию в Linux новых механизмов экономии энергии, появившихся в процессорах Intel серии Haswell и Broadwell. Результат превзошел все ожидания и показал плачевное состояние с работой по оптимизации энергопотребления в Linux. В частности, потребление энергии удалось снизить с 8.5 до 5 Ватт, что значительно продлило время автономной работы системы от заряда аккумулятора.
Причиной выявленных проблем является то, что CPU Haswell и Broadwell не переходят в глубокие режимы энергосбережения, если в активном состоянии находится хотя бы одна из интегрированных подсистем, таких как CPU, GPU и PCH (Platform Controller Hub). PCH обеспечивает работу систем ввода/вывода, в том числе USB и SATA. В Linux по умолчанию отключено использование механизмов снижения энергопотребления для SATA, т.е. интерфейс SATA всегда находится в активном состоянии, что не даёт процессору активировать глубокий режим энергопотребления и сохраняет питание многих частей CPU, потребность в которых отсутствует. Похожее поведение наблюдается и в Windows, но большинство производителей оборудования поставляют в данной ОС дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления.Для решения проблемы для ядра Linux предложен (https://lkml.org/lkml/2015/4/18/76) небольшой патч, который извлекает настройки прошивки на стадии загрузки ядра и добавляет две новые политики энегропотребления: первая на основе выдаваемой прошивкой конфигурации и вторая, повторяющая настройки в драйвере Intel. Использование данных политик позволило при неактивности системы снизить потребление энергии на несколько ватт за счёт того, что изменение состояния линка SATA дало возможность добиться включения режима PC7 вместо PC2.
При этом исследование ещё не закончено, так как предстоит учесть влияние на выбор режимов энегосбережения состояния других компонентов, в частности, GPU. Например, активность экрана приводит не только к затратам энергии на его работу, но и к нахождению во включенном состоянии дополнительных компонентов чипсета. В спецификации Embedded Displayport 1.3 определён интерфейс Panel Self-Refresh, позволяющий согласовать отключение линка с GPU, сохранив при этом содержимое экрана. Патчи для включения подобного режима уже подготовлены для систем Intel, но пока не включены по умолчанию.
Проблемным также остаётся вопрос доведения всех доступных средств энергосбережения до пользователей. Компания Intel обеспечила в ядре поддержку всех возможностей управления питанием для своих систем, но данные возможности лежат мёртвым грузом и остаются неактивированными. Задача применения данных возможностей и выбора оптимальной политики энергопотребления ложится на дистрибутивы, которые не спешат что-то менять и склоняются к использованию консервативных универсальных настроек, не учитывающих возможность дополнительной оптимизации для отдельных систем.
URL: http://mjg59.dreamwidth.org/34868.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42119
Марк должен исправить ситуацию в своём дистрибутиве.
Примерно вот так он должен исправить...> Мэтью Гаррет, известный разработчик ядра Linux и лауреат премии за вклад в развитие свободного ПО, опубликовал результаты эксперимента по задействованию в Linux новых механизмов экономии энергии, появившихся в процессорах Intel серии Haswell и Broadwell. Результат превзошел все ожидания -- ПРОЦЕССОР НАЧАЛ ОТДАВАТь ЭНЕРГИЮ ОБРАТНО В СЕТь, НА ОДНОМ ИЗ НОУТБУКОВ ДАЖЕ ВЗДУЛО БАТАРЕЮ !!!
> Марк должен исправить ситуацию в своём дистрибутиве.Проклятые проприерасы успели таки обогнать и Мэтью, и Марка, и стратегических онолитегов с опеннета:
> Причиной выявленных проблем является то, что CPU Haswell и Broadwell не переходят в глубокие режимы энергосбережения, если в активном состоянии находится хотя бы одна из интегрированных подсистем, таких как CPU, GPU и PCH (Platform Controller Hub). PCH обеспечивает работу систем ввода/вывода, в том числе USB и SATA. В Linux по умолчанию отключено использование механизмов снижения энергопотребления для SATA, т.е. интерфейс SATA всегда находится в активном состоянии, что не даёт процессору активировать глубокий режим энергопотребления и сохраняет питание многих частей CPU, потребность в которых отсутствует. Похожее поведение наблюдается и в Windows, но большинство производителей оборудования поставляют в данной ОС дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления.
> стратегических онолитегов с опеннета:Сперва прочитал как "стратегических олигофренов". Очень лол!
> Проблемным также остаётся вопрос доведения всех доступных средств энергосбережения до пользователей. Компания Intel обеспечила в ядре поддержку всех возможностей управления питанием для своих систем, но данные возможности лежат мёртвым грузом и остаются неактивированными. Задача применения данных возможностей и выбора оптимальной политики энергопотребления ложится на дистрибутивы, которые не спешат что-то менять и склоняются к использованию консервативных универсальных настроек, не учитывающих возможность дополнительной оптимизации для отдельных систем.Виноваты проприерасы и лично Путен, тут даже сам Марк бессилен что либо сделать !
Ждем какой-нибудь ЦианогенМодОС ...
Зачем ждать, если она уже есть?
вы "изобрели" Tizen, поздравляю :)
который(помимо прочих корпораций) пилит и intel. так что оная фича будет и там.
а если надо чтонить "потоньше и без html5 софтин", то всегда есть форки sailfish или bada(развитие которого замедлено, но не остановлено).
Покажи мне форк Sailfish.
"knowledge itself is power" (c) F. Bacon.
У закрытых программ не бывает форков (почти)
https://cyngn.com/cyanogen-os
> https://cyngn.com/cyanogen-osЭто там где с микрософтовскими зондами то?
Почему последний абзац без пруфлинка?
потому что опеннет - не вики. ваш кэп.
Это как c Kdbus. Не пускают его пока в Mainline Kernel. Так и эти патчи.
В 4.1 ядре будет много новинок и изменений, так чего бы не впихуть было уже в этот релиз терминаторский.
Да, нужно увеличивать время автономной работы. А то что за терминатор, если за два часа батарейка сядет?
Обычный андроид.
Андроид на хасвеле или бродвеле - это далеко не обычный андроид...
Вот, кстати, почему его не пускают в ядро: https://news.ycombinator.com/item?id=9450806> No Greg. Just remove the shit. Really.
>
> We don't add crap that then has to be disabled with secuirity rules just because it was a bad interface. Just make the interface not do it in the first place. It's that simple.
>
> My guess is that pretty much the entirely of the quoted kdbus "speedup" isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server.
> So really. The people who talk about how kdbus improves performance are just full of sh*t. © Linus
> Anyways. "Two key kdbus developers" (ahem) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex".
А по-рууски
Потому что shit.А вот что интересней - это почему оно shit. Не только потому что имплементация отвратительного качества.
>KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
> KDBus was designed with sandboxed applications in mind. <...> without leaking information about the system.Отвечу цитатой Линуса:
> So the whole "capabilities and user information" is really to me a non-issue. It's clearly required information, and if you don't want to expose it, you damn well have absolutely *zero* business talking to system daemons.
Последнее предложение Линус забыл аргументировать
Линус себя всегда аргументацией не утруждал и формальной логикой. "потому что!" его все.
возможно, иначе бы какие-то неочевидные для нас всех, мотивы - были виднее.
Верно подмечено. Но печально не это, а количество людей, которые считают нормой поведение евангелистов типа Линуса. И при случае ведут себя так же.
> евангелистов типа ЛинусаЩЬТО
за что люблю опеннет за незамутненность некоторых комментаторов. Линус типа евангелист.
> Вот, кстати, почему его не пускают в ядро: https://news.ycombinator.com/item?id=9450806
>> No Greg. Just remove the shit. Really.
>>ыхыхых
http://article.gmane.org/gmane.linux.kernel/1930426
> You don't have to enable the metadata if you don't want to use it, it's
> an option :)OK, _that_ argument needs to be stomped out. It had been used before,
and it was a deliberate scam. There is no such thing as optional kernel
interface, especially when udev/dbus/systemd crowd is nearby.Ал Виро няша <s>я хочу от него ребенка</s>
> "Two key kdbus developers" (ahem) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex". When I read that, a big light bulb turned on in my head about what the actual problem is here.
Довольно не простая задача, учитывая разношёрстность железа. К тому же малое время автономной работы - это такая вещь второстепенная, хоть и неприятная, но не ошибка же и не сразу бросается в глаза пользователю, а значит и разработчиков есть соблазн это проигнорировать.
Тут конечно всякие macbook'и выигрывают в автономности в виду чёткого подпиливания ОС под конкретное железо.
Пользователю как раз таки бросается в первую очередь. Так приятно когда твой свеженький ноут живет под виндой 5 часов, а под линуксом 3 не вытягивает. Я даже боюсь представить какая разница будет на макбуке с MacOS и линуксом
Вот ровно наоборот ситуацию наблюдал на нетбуке Samsung N130... под виндой новый шесть-семь часов тянул, под линуксом 8-9
Установи "дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления" и в винде будет 10-12 часов. Неужели так сложно внимательно прочитать новость и сделать логические выводы?
> Установи "дополнительный AHCI-драйвер компании Intel,ЧСХ, большинство пользователей кладут на это с прибором.
Кэп, я же написал "в сравнении". Сравни, например, если у тебя дистрибутив валится с ошибками будет или мало от батареи работать будет. Но и само собой и автономность важна.
стоковая убунта 14.10 на прошке 11 года по датчикам в панеле жила где-то на час меньше osx
т.е. где-то 5-6 часов против 6-7, а кинцо смотреть так и дольше выходило почему-то
смотря в чём смотрел кино, vlc этак только в версии 2.2 сделали нормальное декодирование видео
> смотря в чём смотрел кино, vlc этак только в версии 2.2 сделали
> нормальное декодирование видеоЛично мой ноут в убунте спокойно тянет часов 7 с гаком если браузить и т.п. не слишком активные нагрузки. В винде он работает даже меньше чем в убунте. Правда там более древний проц и ему эти улучшенные режимы не грозят.
На моем двухгодовалом 13" макбуке макос - 9,5ч., убунту 14.04.1 - 4,5ч.
> На моем двухгодовалом 13" макбуке макос - 9,5ч., убунту 14.04.1 - 4,5ч.Есть ещё один нюанс. С видеосистемой тоже негладко. Например на OS X браузеры (safari, chrome, opera) умеют аппаратно декодировать видео, а на линуксе такого нет. Если смотришь котят на ютюбчике, то батарея сильнее будет разряжаться под линуксом нежели в OS X.
Так 2015 год. Когда ж уже научится линукс такому? Успевают люди новые вещи делать со всеми ништяками, а линуксу треть века почти, а все еще в древности.
А Вы на список браузеров посмотрите сначала, а потом ответьте себе на вопрос: это точно Linux виноват?
При чём тут это? Я написал список браузеров, которые под OS X поддерживают GPU декодирование, под линуксом этот нулевой.
> При чём тут это? Я написал список браузеров, которые под OS X
> поддерживают GPU декодирование, под линуксом этот нулевой.ну, ситуация когда конкретный юзверь полагает что "под линуксом список браузеров с оффлоадингом рендеренга на GPU - нулевой" - не вина Линукса или браузеров(в тч с оного, поддержкой).
потому отчасти, что юзанье оного - предполагает неслабую мантру RTFM, перед.
ибо 4 разных интерфейса этого декодирования, три разных вендора GPU(каждый со своими тараканами в реализации каждого) в отличие от однородной "MacOS"-и где все прибито гвоздями и анально прозондированно. настолько, что даже гугль по-дефолту выключает в хроме(и намерен - впредь)оное в браузере.
с приходом Vulkan - оно наверное станет более хомячково-френдли. наверное. но не факт.
Пруф заведения GPU декодирования видео на nvidia карте хоть в каком-нибудь браузере под линуксом, пожалуйста.
Про гугль враньё, они в начале этого года запилили GPU декодирование видео под OS X. Разве что до стабильной версии вот неуверен что ещё дошло. Проверял - работает. https://code.google.com/p/chromium/issues/detail?id=133828
нудк для OSX запилили, а под Linux - выпилили и выключенным намерены оставлять и впредь.
> Пруф заведения GPU декодирования видео на nvidia карте хоть в каком-нибудь браузере под линуксом, пожалуйста.Сойдет? firefox+gstreamer
http://www.opennet.me/opennews/art.shtml?num=33651
Не сойдёт - это теория, которую я и так знаю. Реальный тест HTML5 видео этак 4K разрешения на невидии в фурифоксе, чтоб была около нулевая нагрузка на процессоре, и чтоб не падало от перемоток и пауз. Хотя пускай и не 4K видео, а хотя бы 1080p этак.
Собственно говоря вот такой RTFM:
Под chromium c vdpau вообще дохлый номер.
Под фурифокс вроде как что-то есть, но только этак с GStreamer-vaapi версии 0.5.9 и старше (он, например, не успел войти в ubuntu 14.04 LTS). Для vdpau ещё надо впендюривать прослойку vdpau-va-driver. Как это всё в реальности работает (плохо/хорошо) - без понятия, не пробовал, ибо сижу как раз на ubuntu 14.04. Например, VLC просто отвратительно работал через vdpau-va-driver, пока в VLC 2.2 не сделали прямую поддержку VDPAU.
> это точно Linux виноват?Ну и для пользователя неинтересно, кто именно виноват из цепочки (разработчики ядра или видеосистемы или браузера или ещё кто), для него есть результат, что не работает, и в конечно счёте для него виноват линукс.
>> это точно Linux виноват?
> Ну и для пользователя неинтересно, кто именно виноват из цепочки (разработчики ядра
> или видеосистемы или браузера или ещё кто), для него есть результат,
> что не работает, и в конечно счёте для него виноват линукс.на Linux, где "пользование" самой ОС, включая ее установку нередко или конфигурирование - предполагают действия и знания, выходящие ДАЛЕКО за описанные пределы - отнюдь.
ты хочещ чтобы йутубчик к железу доступ имел?молодеееец
> ты хочещ чтобы йутубчик к железу доступ имел?Он и так имеет доступ к железу - к монитору. Если кроме него будет еще и видеодекодер - это наверное не так уж страшно.
Стесняюсь спросить - вам браузер картинки через либастрал передает или прямо в /dev/crystal_ball выводит?
Вообще-то /dev/crystal_ball это тоже «железо».
> Есть ещё один нюанс. С видеосистемой тоже негладко. Например на OS XНапример в OS X OpenGL реализован в такое сpaное гoвно, что его делает НА ТОМ ЖЕ ЖЕЛЕЗЕ опенсорсная MESA.
Не то самое, но да, более медленное, но к тебе энергосбережения это совсем не относится.
>Эксперимент с CPU Intel позволил на 40 процентов снизить энергопотребление в Linux...в режиме простоя.
Насколько я понимаю, тот же эффект достигался вручную:
/etc/udev/rules.d/hd_power_save.rules
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"
О чем можно говорить?... Когда даже управление частотами реализовано не полностью. В Windows 1.15 > 1.2 > .. Linux даже не в курсе что есть режим с 1.15 Ггц, показывает только 1.2 и выше. Разгон происходит обрывками.... Называется "все реализовано"
Я тебя удивлю дорогой спец, управление частотой и электропитанием это ACPI и ты можешь его патчить, если то что в железе тебя не устраивает. Хотя нет, ты не можешь.
> Называется "все реализовано"Большая часть таких "проблем" называется "мы забили на стандарты - лишь бы работало под виндой" со стороны впаривателей железа.
Простейший пример:
смотрим в дамп DSDT (это часть ACPI, "интерфейс к железке") и должна, по идее, быть не особо зависимой от ОСи
(взял отсюда: http://blog.yjwong.name/fixing-display-backlight-hotkeys-on-.../)If (CondRefOf (\_OSI, Local0))
{
If (_OSI ("Linux"))
{
Store (0x03E8, OSYS)
}If (_OSI ("Windows 2001"))
{
Store (0x07D1, OSYS)
}If (_OSI ("Windows 2001 SP1"))
{
Store (0x07D1, OSYS)
}If (_OSI ("Windows 2001 SP2"))
{
Store (0x07D2, OSYS)
}
и т.д - вплоть до:
If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
...
If (MCTH (_OS, "Microsoft Windows NT"))
{
Store (0x07D0, OSYS)
зацениваем поддержку всех версий форточки и cмотрим "вкусняшки"
Method (_Q0E, 0, NotSerialized) // _Qxx: EC Query
{
If (LLess (MSOS (), OSW8)) //если не восьмерочка, сделай так
{
SBRN ()
}If (LGreaterEqual (MSOS (), OSVT)) //виста или выше, сделай эдак
К сожалению, автор выложил только часть дампа, поэтому в качестве другого примера:
http://www.tonymacx86.com/dsdt-database.php - Laptops - HPIf (((OSYS > 0x07D0) && (OSYS < 0x07D6)))тут тоже - всякие форточки идентифицируются как 0x07D*, а линукс - 0x03E8, т.е. "всякие прочие".
{
Notify (PCI0, Arg1)
}
Else
{
Notify (IGPU, Arg1)
}
ТТ.е. мы имеем не только "грязные хаки" для отдельных версий виндовс, но и код типа "если не винда ->fall_back_шоб_было_а_как_оно_работает_дело_десятое".И это, смею вас уверить, для большинства железок "для домохозяйки" - норма.
И пока основная целевая аудитория использует виндовс, а пользователи "маргинальных ОСей" частенько предпочитают поныть на форумах о плохой поддержке железа пингвином (но при этом купить железку подешевле, не обращая внимания на качество) - вряд ли что-то изменится.
вы абсолютно правы. к сожалению.
Думаешь? Если бы всё было так просто, достаточно было прикинуться Windows и всё бы заработало. Но всё сложнее: под Линукс это НЕ РАБОТАЕТ, а иногда даже аппаратуру портит, а под Windows работает. И разработчик железа не будет разбираться кто и где в ядре накосячил.
> Думаешь? Если бы всё было так просто, достаточно было прикинуться Windows и
> всё бы заработало. Но всё сложнее: под Линукс это НЕ РАБОТАЕТ,А чего сборник трудов Гаррета не приложил? Пусть самообразовывается.
> а иногда даже аппаратуру портит, а под Windows работает. И разработчик
> железа не будет разбираться кто и где в ядре накосячил.И стрелки там правильно и аргументированно переведены.
Пример порчи аппаратуры приведите, пожалуйста.Не забываем также, что тестировать железо на совместимость и пилить для него некосячные драйвера должен по умолчанию всё-таки разработчик самого железа. Ну или хотя бы спеки своей вундервафли открыть - чтобы по крайней мере можно было понять, кто и где накосячил.
> Пример порчи аппаратуры приведите, пожалуйста.Тебе DSDT настроить чтоб у тебя cpu в буке на полной моще всегда работал? и в результате выгорел? или еще чего пожелаете?
> достаточно было прикинуться Windows - а до этого отловить 1000 обезьян, дать им в лапы клавиатуры, наладить автотестирование и, главное, хорошенько задокументировать весь этот процесс, чтобы, когда (рано или поздно) одна из обезьян повторит специфичную реализацию ацпи какой нибудь версии виндовс, смело отметать все претензии типа "содрали код! Платите!!" со стороны МС :)fixed
Ведь действительно, разработчики линукса такие недалекие и наивные - вначали думали, что достаточно просто придерживаться спеков, а потом - не догадались прикинуться виндосом (при этом отреверзив имплементацию и переделав ядро так, чтобы можно было полностью "делать как в винде").
И все для того, чтобы ныт^W уважаемые анонимы опеннета могли и дальше покупать дешевые железки, (конечные до-)разрабы которых забивают на стандарты.
Да, линукс-разработчики и анонимы с опеннета - это сила! Вместе мы спасем линукс! :)
Сразу видно человека заводившего хакинтошь
> мы забили на стандарты - лишь бы работало под виндойНа самом деле: "мы специально долго трудились и забивали на стандарты, чтобы работало только под Вындой и не работало в Линукс" (но таки надорвались).
"Проблемным также остаётся вопрос доведения всех доступных средств энергосбережения до пользователей. Компания Intel обеспечила в ядре поддержку всех возможностей управления питанием для своих систем, но данные возможности лежат мёртвым грузом и остаются неактивированными."Это факт, и не только в драйверах Intel. Юзерспейс и дефолты Linux требуют развития.
> ложится на дистрибутивы, которые не спешат что-то менять и склоняются к использованию консервативных универсальных настроеквсё правильно делают дистрибутивы.
универсальность -- важнее парочки сохранённых Ватт.
нам не нужна ситуация когда для каждой модели компьютера нужен индивидуальный дистрибутив (с индивидуальной подгонкой драйверов).
а ситуация которая творится сейчас в сфере операционных систем для смартфонов -- просто абсурдна.
Дистрибутив - не нужен. А вот индивидуальный конфиг - вполне. Тем более, что это суровая системщина с юзерспейсом пересекающаяся весьма слабо - так что эти конфиги дистрибутивам как раз совершенно ортогональны.
ну пусть так.. лиж бы только эти конфиги НЕ засовывали бы внутрь дистрибутивов (а выкладывали бы отдельно бы :))
Да какая разница. Ну вон таскается же terminfo какой-нибудь. Так же и это можно таскать. Просто раз оно софту ортогонально - то заниматься созданием такого должен отдельный проект. А дистры потом, как обычно, его результаты опакетят и себе в репозитории положат.Впрочем, "как сделать удобное community-driven хранилище конфигураций" - тема отдельная и очень большая. И абсолютно непаханая.
Могу ошибаться, но утилита laptop-mode-tools решает проблему со сном SATA.
Сейчас в моде TLP.
А произвоительность на сколько процентов упала после снижения энергопотребления на 40%? На 60%?
в режиме ожидания же
нет ничего хуже процессоров с закрытыми фирмварями
Тут как раз MIPS открыли
http://linuxgizmos.com/imagination-to-release-open-mips-desi.../
Дело не в закрытых фирмварях, а наоборот. Написали же, Интел накодила в ядре все необходимое. Осталось дело за малым - кастомизировать профили для каждого из процессоров и оборудования. Рутинная работа, чем в опенсорсе не принято заниматься: удобные дефолты и предустановки
> Дело не в закрытых фирмварях, а наоборот. Написали же, Интел накодила в
> ядре все необходимое. Осталось дело за малым - кастомизировать профили для
> каждого из процессоров и оборудования. Рутинная работа, чем в опенсорсе не
> принято заниматься: удобные дефолты и предустановкиЗа весь опенсорс отвечаете, да?
может и в андроиде чего переделают, и тогда смартфоне на его базе поставят новый рекорд без розетки -два дня...
у меня при активном использовании (мессенджеры, интернет, почта, органайзер и т.д.) стандартная зарядка раз в четыре дня.
подскажите куда мне обратится чтобы мне что-то подправили и было как у всех - один день?
Это не как у всех.
Как у всех - это нафиг мессенджеры, интернет, почта, органайзер.
Оставляем только телефон и СМС.
Играем в игрушки каждую свободную секунду.
Они выключили процессор ?!?! :))))
А, вот почему китайские роутеры не спят и их приходится выключать!
Через одно место работающие ACPI это норма для производителей железа. Одни костыли костылями погоняют.
Играю в игры в месенджерах не включая экран батареи хватает на восемь месяцев..
> Играю в игры в месенджерах не включая экран батареи хватает на восемь
> месяцев..Ну я с батареей КАМАЗа и не такой рекорд выдать смогу..
> Похожее поведение наблюдается и в Windows, но большинство производителей оборудования поставляют в данной ОС дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления.Я один вижу противоречие внутри этой фразы?
Собственно, проблема с производителями железа не нова:
http://jakobz.livejournal.com/244504.html
А как-то кроме отката, можно вернуть обратно kde4 на openSUSE Tumbleweed?
ой, темой ошибся.