?

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

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

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

ну а куды деваться блин просюмерам-то? Паллиативов можно наизобретать разных, но нормального решения никто не предлагает ...

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

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

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

увы, ответ лежит совсем НЕ в технологической плоскости, т.е. НЕ важно масштабируема ли сама платформа (или любой другой параметр, который достижим увеличением силы и/или качества мозгов на техническом направлении)...

Понимаю. Но что ж делать просюмерам-то?

(Deleted comment)
никакого отношения - так, штатный бездельник :)

(Deleted comment)
мешают причины не-технического характера, поэтому я могу прыгать с разбега на стену, но это все равно ничего не изменит.

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

и чтобы раз, и навсегда - всем желающим произвести акессуары, ОЕМы п'гактически даг'ом дают размеры и посадочные места, так вот если будет нужно, подкину контакты... а вот теперь попробуйте СДЕЛАТЬ - а то ведь советчиков на площади всегда много, а при первых же простейших попытках предложить сверстать-сосчитать BoM все киснут и разбегаются...

(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
хех. а графики эти коммерческая тайна, как водится?

в зависимости от того, что хочется получить - исходные данные даром лежат, часть на ITT, часть на talks.maemo.org, часть разбросана по интернету... агрегированные данные очевидно небесплатные - емнип, финское корпоративное право запрещает отдавать даром то, что сделано за счет корпорации, без решения board of shareholders (в свое время именно они принимали формальное решение о том, что kernel IPR возвращается в комьюнити). как доворитесь о цене - так и купите.

часть этих данных была использована при подготовке co-creation workshops во время maemo summit
http://www.flickr.com/photos/markosaari/3995655484/
http://www.flickr.com/photos/markosaari/3995655376/
http://www.flickr.com/photos/markosaari/3995655560/
http://www.flickr.com/photos/timsamoff/4016955345/
http://www.flickr.com/photos/timsamoff/4016955805/
http://www.flickr.com/photos/timsamoff/4017717962/
http://www.flickr.com/photos/timsamoff/4016956407/
http://www.flickr.com/photos/timsamoff/4016955805/

да поищите сами на фликере по тэгу maesum - там 903 фото с таким тегом... заодно ручки окунете в аналитическую работу...

Тем не менее, видимо незнакомые с понятием смерти-через-CV китайские друзья взяли и сделали:


Внешний размер: 67 x 120.5 x 11 mm
Экран: 4.3"

То есть все еще телефон, все еще с легкостью помещается в руку, но экран как у N8x0. Да, без клавиатуры, увы.

PS: Кстати, идею кредла всячески поддерживаю. Но у вас же сейчас сделано так, что если втыкать в USB кредл, то экран будет вертикально, вверх ногами! Таким образом под N900 придется либо конструировать горизонтальный кредл с разьемом слева, либо добавлять в систему недостающие ориентации (180o и 270o). AFAIK, железяка их вроде позволяет.

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

  • 1