?

Log in

No account? Create an account
Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
Топка Переключателя Контекста
Speaker Rabbit
abbra

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

Обычно виртуализацию используют для того, чтобы экономить. Экономят на электроэнергии, на расходах на покупку серверов, "уплотняют" нагрузку на единицу серверной мощности и повышают ARPU в расчете на одного хостера. В N900 виртуализация используется для реализации идей Робина Гуда -- отнять у богатых и раздать бедным. Или, как говорилось, у нас все для человека и мы знаем имя этого человека -- Пользователь.

В ядре Linux поддерживаются несколько методов виртуализации, среди которых выделяется виртуализация методом контейнеров. Для контейнеров характерна так называемая "легкая виртуализация" -- все контейнеры работают под управлением одного и того же ядра, а вот доступ к дисковому пространству, к пространству процессов и памяти у них разграничен. Один контейнер не видит, что творится в другом контейнере. Из знакомых решений такого типа -- OpenVZ (и коммерческий вариант Virtuozzo от Parallels), Linux Vserver и еще несколько альтернатив.

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

Независимое дисковое пространство умеют в POSIX-совместимых системах уже довольно давно. Изоляция "в chroot" -- нормальная практика с 1982 года, когда системный вызов chroot(2) появился в том, что стало через 17 месяцев версией 4.2BSD -- для тестирования установки и сборки системы. В девяностые в Plan 9 идея изоляции пространств имен была доведена до логического конца, с изолированными сетевым пространством для каждого процесса. В ядре Linux адаптация изолрованных пространств продолжается до сих пор, отдельные типы пространств можно использовать довольно стабильно с 2.6.25.

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

Control groups или cgroups, представляют собой как раз такой общий знаменатель. Тот или иной вариант ресурса описывается определенным типом управляющей группы, а процессы в системе могут быть добавлены в "пространство" соответствующей управляющей группы. В этом случае использование ресурсов этими процессами будет подсчитано согласно и учтено.

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

Это очень схематичное описание, для приблизительного представления. k001 может рассказать более подробно, а у меня совсем иная цель.

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

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

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

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

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

Все это сказывается положительным образом на энергопотреблении. Ядро бы и радо отключать определенные аппаратные устройства и уходить в режимы сниженного энергопотребления, да хорошо бы, чтобы приложения не заставляли невовремя из этих режимов выходить. Я теперь не могу смотреть на скринсейверы на десктопах, "как же они расходуют-то энергию!". Так и представляются толпы замызганых прерываний, в поте лица тягающие сигналами неповоротливых и прожорливых приложения в топку Переключателя Контекста и Господина Батарейкина.

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

Tags:


  • 1
:) Ты тролль.

И strangestone тоже?

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

Вообще, я что-то тут не понимаю. Всего семь лет назад у меня в качестве домашнего компьютера стояло устройство, которое имело меньше RAM и вычислительной мощности чем N900. Оно обслуживало до трех интерактивных пользователей одновременно, роутило сетку из 100 компов, предоставляло для них почту и ньюсы, и еще и web-сервером работало.

Три года назад у меня ноутбук был еще более слабый.

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

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

Ищите. У вас там явно резерв на порядок есть.


(Deleted comment)
> И, скажем так, я слабо представляю зачем мне еще туда надо будет зайти снаружи по ssh кроме этого.
keyword: "нормальная клавиатура"

Любые работы на таблетках, сложнее чем одна строка в шелле - гораздо удобнее делать извне (ну если не брать вариант изврата подключения внешней клавы через usb host)

(Deleted comment)
А сколько ватт кушал ваш домашний компьютер?

Подозреваю, в этом вся закавыка. Мегафлопс\вт растет гораздо медленнее, чем мегафлопс вообще.

Насчет вьюеров картинок дискуссию не слышал, но могу сказать что PSP у меня (64 RAM, 2x333mhz) умеет вменяемо показывать чертежи в JPG (~14000x4000), с pan-zoom, не ахти как быстро, но и без лагов.

Впрочем, это упирается в подточенные инкрементальные декодеры все.

Делаем, делаем. Мой текущий лозунг -- "100 Мпиксел не предел".

Что касается ssh -- текущая политика его деклассирует, в смысле не учитывает вообще. Это будет поправлено.

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

Что касается ssh -- текущая политика его деклассирует, в смысле не учитывает вообще. Это будет поправлено.
Кстати, тут надо думать на что лучше смотреть - конкретно на ssh или вообще на активность в псевдотерминалах. Если отслеживать активность в псевдотерминалах, это покроет кроме ssh и еще ряд применений.

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

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

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

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

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

он ни разу не тролль :) он просто отказывается воспринимать происходящее вокруг него "как оно есть", если/поскольку оно не вписывается в его картину мироздания :) одно из следствий этой леммы: поскольку он родился и вырос в стране, где природо- и энергосбережение никогда не было приоритетом номер 1 (чтобы там не говорили политиканы своими языками т.е.), само положение вещей "у нас своего ничего нет, а воровать - нельзя, поэтому все ресурсы - дорогие" не вписывается в его менталитет... и именно поэтому он не понимает как так может быть, что батарейка что-то там диктует свое, и как вообще так может быть что элементам системы дадены какие-то права, которые в этом конкретном случае явно идут как минимум поперек его убеждений... другим следствием является (не особенно приятная) мысль о том, что многим россиянам свойственно то же самое заблуждение, что и гражданам США, а именно - что электричество появляется из розетки :) поэтому он готов сделать все, чтобы оно там было всегда, даже на использование атомной энергии... потому что иначе ему прийдется меняться и свыкнуться с мыслью о том, что жечь электричество как попало нельзя, и тд.

все что выше написано ни в коем разе не попытка прилепить ярлык к vitus_wagner - он далеко не один в широких стройных рядах, и было бы глупо тыкать в него пальцем. Просто в силу природного ума и других талантов, он в этом направлении заходит гораздо дальше :) И кто я такой чтобы поучать и менять человека в возрасте, сильно отличающемся от младенческого?

я почему-то думаю что шансы найти дистрибутив с более вменяемым power management (на одном и том же hardware, и теми же use time expectations в рамках желаемой функциональности) настолько близки к нулю... и даже если он сменит желаемую им функциональность, все равно батарея при этом ни в коем разе не будет наращивать свою емкость, только уменшать с каждым днем использования псоле схода с конвейера - судя по всему, с этой стороной физики батарей ему все еще предстоит познакомиться :)

Если же произойдет чудо и такой дистирибутив найдется - мы сможем сэкономить на содержании всей power management group ;)

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

ну погремушку как раз можно сделать из (почти) всего на свете.

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

Нет, нельзя. Инженеры выдали Вам батарейку. В батарейке 1500mAh. Вы должны отработать от этой батарейки минимум 12 часов. Как Вы это будете делать никого ниипет, но все остальные требования менеджмента к устройству должны также быть выполнены.

  • 1