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

(Deleted comment)
На n900 будет VLC? ;)

(Deleted comment)
(Deleted comment)
Так именно перестаёт или медленно всё? И какая частота процессора /proc/cpuinfo ?
В общем случае, системе нужно какое-то время, что бы понять, что нужно поднять частоты. События от тачскрина, насколько я знаю, способствуют более быстрому подъёму частот.

(Deleted comment)
А вот такая штука, как "скринсейвер в стиле s60" - редко обновляемая картинка на рефлективном экране без подсветки, в эту архитектуру не вписывается?

Честно говоря, с постоянно обновляемыми экранами -- не очень. С экраном с отдельным буфером -- может быть и впишется, но все равно все настолько неоднозначно... В s60 все же количество пикселей, например, на N95, было все-таки в 2.5 раза меньше, да и энергопотребление у системы было совсем другое.

Да, блин, Точно надо маемо сносить и ставить более доступный пониманию человека дистриутив.
Мало того, что я так и не разобрался как сделать, чтобы в maemo 3/4 пользователя звали не user а vitus, так еще теперь получается что устройство не предназначено ни для чего кроме вывода на экран и наушники.

(Deleted comment)
(Deleted comment)
Вай-вай, сколько ж это оно стоит - половину самолёта!
Надеюсь, через годик подешевеет баксов до 400...

Я бы не решился летать на таких самолётах ;)

Во глюкало то...

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

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

Все-таки интересно, услышит ли нокия мой (и не только мой) стон - сделать устройство с размером экрана хотя бы как 810 и НОРМАЛЬНОЙ клавиатурой? Или производители мобильных устройств издеваются? От 12-клавишной морды классического мобилы перешли к КАК БЫ qwerty, но это КАК БЫ настолько сильно, что делает всю затею почти бессмысленной...

твой голос ДАВНО был услышан - на графиках user feedback увеличение клавы стоит в первых строках (межды 2 и 5, в зависимости от разреза), приьем не первый год.

Проблема so far заключается в том, что никто из product management + marketing не хочет выходить на эту тропу: до сих пор, все кто по ней пошел, с точки зрения бизнеса "умер" (палм, иже и понеже, и чем больше экран и клава, тем быстрее умирали), и никто не хочет положить на алтарь рынка строчки своего _личного_ CV. В том смысле, что они все нацелены на удовлетворение той части рынка, что дает максимальный профит. Это судьба prosumer market segment, к которому мы с тобой принадлежим - мы в меньшинстве, и никто нам за рупь сорок собаку не будет из будки доставать (в том смысле, что современный бизнес фактически умерщвляет все, что хоть на секунду позволяет благотворительность).

Единственный виабельный метод, хотя и паллиатив "по всей морде" - это раскладная клава с крэдлом для устройства. Она все-таки ухудшает reliability всего пакета (хотя бы в механическом плане), но позитив в том, что ее можно "срастить" с активным USB-хабом, и таким образом (заодно) решить проблему несовместимости батарейности устройства и нужды в USB host...

(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
Ммм, ну и нямка этот n900

Спасибо за телефон, у меня их уже 2 :)

> Я теперь не могу смотреть на скринсейверы на десктопа

> , "как же они расходуют-то энергию!".

Типичный xscreensaver, к примеру, отправляет SIGSTOP рисовалке с того момента, как включается DPMS и показывать красивости бесполезно.

(Я лично никогда не любил CPU-hogs screensavers — поскольку понимаю, что ради финтифлюшек слишком уж много энергии тратится.)

Что касается классификатора — вы переделали планировщик, или просто навернули что-то внешнее?…

Re: > Я теперь не могу смотреть на скринсейверы на дескто

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

(Deleted comment)
  • 1
?

Log in

No account? Create an account