?

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
(Deleted comment)
Как это реализовано в других телефонах, я не знаю. :)

в WM - через Ж, очевидно :)
держу в руках glofiish X800 - и очень хочется его раз...ть за тормоза, при том, что там довольно мощный проц

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

В WM судя по всему, немногим более, чем никак, потому что оно ухитряется и батарейку высаживать и события терять ;-)

Однако пока что N900 держит батарейку так скажем сутки, а WM побольше. В среднем.

Но не хочу холиваров. Просто хочу чтобы N900 дольше от батарейки работал. ;)

WM в режиме always online с активным SIPом, push email и мессенджерами держит батарейку так скажем поменьше. Практически для всех устройств это скорее "день", чем "сутки". Но я тоже хочу ;-) Symbian-то двое суток держал. Хотя и батарейка была чуть побольше.

Edited at 2009-12-11 05:48 am (UTC)

По существу согласен. Но всё-таки чисто субъективно WM пока батарейки лучше держит. Айфоны и андроиды я лично не использовал, но вроде тоже слегка подольше. Это чисто субъективно.

И я в принципе понимаю, что N900 не зря кушает.

Ну я бы не сказал, чтобы даже субъективно могло быть чем-то лучше. Айфон и андроид получше винды, но не более. Просто не надо сравнивать always online с режимом standby, только и всего. А сравнивать не получится, потому что айфон и wm в этом виде вообще никуда не годятся, а андроид туда-сюда, но тоже не фонтан.

Опять же, сравнивать нужно сопоставимые вещи. Объем прокачиваемых данных, необходимых для обновления экрана, у устройств на Maemo в среднем в 2.5 раза больше типовых устройств на WM и того же iPhone, например. Это накладывает свои отпечатки. Да и количество работающих приложений (и что с ними можно делать) тоже. Графический адаптер немного функциональнее. Все это ест батарейку.

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

Как программист я это всё понимаю. А вот как пользователь хочется подольше. ;)

Я для себя эту проблему решил -- я не торчу в джаббере где попало. В принципе, на это обычно времени и так нет. :) А режим использования -- вот два дня совещаний по два-три часа звонков подряд, остальное время музыка через BT-наушники. Синхронизация почты каждые полчаса в рабочее время. Хватает на полтора-два дня. Естественно, что экран практически все время выключен.

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

теоретически, это можно сделать самому, добавив еще один элемент в policy framework, он есть в виде отдельно выделенного архитектурного компонента. естественно, со всеми последствиями - stakeholders always take whole responsibility.

не удивлюсь, если этот элемент можно будет запакетировать в .deb, положить на maemo.org в PPA и иметь "всегда up to date"

Однако пока что N900 держит батарейку так скажем сутки, а WM побольше. В среднем.

будет лучше на следующей дельте апдейтов... но любой факап в 3-сторонней аппликухе будет по-прежнему "выливать заряд батареи в помойку" очень быстро. особенно этим славится community code - прочистка длится до сих пор именно потому, что люди живущие "от розетки" редко утруждают себя необходимостью писать код эффективным "и с батарейной точки зрения тоже".

Просто хочу чтобы N900 дольше от батарейки работал. ;)

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

  • 1