Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Пройти мимо этой новости не получится, т.к. она косвенно скажется и на нас тоже. Появилась новая реализация кодека H.264, от компании Cisco, одного из лицензиаров патентов на идеи, чья т.н. "интеллектуальная собственность" (которой, разумеется, не существует), входит в патентный пул печально известного вымогателя, MPEG-LA.

Вскоре в IETF будет обсуждение по поводу стандартов на видеосвязь в интернете, и пока большая часть имеющих право голоса склонялась к открытому VP8, в т.ч. и потому, что H.264 невозможно использовать без уплаты дани рэкетиру. Юристы Cisco придумали, как обойти проблему - если вы выпускаете продукт, который скачивает предсобранные блобы с сайта Cisco, то платить вы не обязаны. Если же вы предварительно скачаете блобы (или соберете из исходников), то платить придется. Такова юридическая логика.

Письмо в IETF уже откомментировал создатель формата Ogg и аудиокодека Vorbis, участник Fedora, Christopher “Monty” Montgomery. Он пишет, что пора признать суровую правду - мы, OSS-коммьюнити, проиграли эту битву войны, и юзеры будут платить (через включение стоимости лицензий в товары, например) рэкетиру. Стартовые условия были неравны. Но война с цапками от мультимедиа еще не закончена, и впереди у нас есть шанс переломить ситуацию, т.к. вот вот начнется битва за видеокодеки нового поколения, где у нас позиции лучше, чем у вымогателей. Открытых решений сразу два - Daala от Xiph (на последней конференции по GStreamer в Эдинбурге, Gregory Maxwell рассказывал об истории его разработки, и на LWN уже есть рекап его выступления) и VP9 от Google, и они оба немного обгоняют по готовности H.265 / HEVC, за которым стоит все тот же бандит, MPEG LA.

Ну и ожидаемое. Mozilla Foundation согласилась использовать кодек от Cisco в будущих версиях Firefox.

Инженер Red Hat, Peter Zijlstra, переделал механизм CPU hotplug в ядре.

Еще совсем недавно, технология добавления микропроцессоров без остановки системы не была очень актуальной для пользователей. Лишь счастливые системные администраторы мэйнфреймов (администрирование мэйнфрейма дает почетное право запостить скриншот с настоящим мэйнфреймовым uname -a, на зависть администраторам Linux-систем) рассказывали, как здорово на лету заменять микропроцессоры без остановки системы. Обычно, количество микропроцессоров в системе изменялось лишь в момент выключения. Все изменилось с массовым внедрением облачных систем и виртуализации. Пользователи все чаще спрашивали - если мы абстрагировались от "физического" оборудования, то можем ли мы добавлять ядра в виртуалки в ЧНН, и отбирать их позже? К сожалению, несмотря на практическую ценность и техническую реализуемость в Linux, делать это не советовали (например, можно обратить внимание на доклад Михаила Кулемина о динамическом управлении ресурсами в KVM c прошедшего Fedora Virtualization Day). Одной из причин была низкая эффективность ряда механизмов в ядре, используемых при подключении и отключении микропроцессоров. Как раз этим и занялся Peter.

В статье на LWN история изменения описана подробно, а мы лишь вкратце раскажем. Суть в том, что нельзя просто так подключить и отключить ядро - kernel должен быть готов к этому. Любой поток может заблокировать CPU hotplug, и сейчас делается так - есть две функции, get_online_cpus() и put_online_cpus(). Первая увеличивает специальный глобальный счетчик на единицу, каждый раз, когда вызвана, а вторая, соответственно, уменьшает на единицу. В каждой из этих двух функций, код очень простой и понятный. Например, в get_online_cpus():

mutex_lock(&cpu_hotplug.lock);
cpu_hotplug.refcount++;
mutex_unlock(&cpu_hotplug.lock);

Чтоб произвести добавление или удаление ядра нужно дождаться, пока счетчик cpu_hotplug.refcount упадет до нуля, захватить мьютекс cpu_hotplug.lock, изменить количество ядер, и отпустить мьютекс cpu_hotplug.lock.

Простой и понятный, к сожалению, совсем не означает "эффективный" и "быстрый". Проблема в том, что изменение количества ядер происходит редко (как уже было сказано, порой один раз за время работы машины), а вот вызывать get_online_cpus/put_online_cpus система может очень часто. Это приводит к серьезной потере производительности, т.к. захват мьютекса и изменение глобального счетчика затрагивает сразу все процессорные ядра системы (на то они и глобальные объекты). Peter пришел к выводу, что для задачи требуется написать специализированный механизм синхронизации, не использующий мьютексы почти никак.

Для начала Peter разделил все потоки на две группы - те, кто полагаются на неизменное количество ядер ("читатели", которые вызывают get_online_cpus/put_online_cpus), и те, кто устанавливают его ("писатели"). Peter решил сделать так - заведем по одному локальному счетчику количества "читателей" на каждом из ядер микропроцессора, так, что его увеличение или уменьшение будет работать независимо от других ядер, а вот "писатель" будет устанавливать специальный глобальный флаг, перенаправляющий новые процессы "читателей" по старому, медленному пути, ждать завершения уже стартовавших процессов быстрых "читателей" (обнуление всех локальных счетчиков "читателей"), а уж потом начинать изменение используя старый медленный алгоритм. Подключение процессора это немного замедлит, зато ускорит работу "читателей". К процессу обсуждения механизма подключился его коллега из Red Hat, Oleg Nesterov, предложивший вариант уменьшения времени ожидания "писателем" с использованием RCU, что еще улучшит ситуацию.

Изменение можно ожидать начиная с версии 3.13 - вряд ли успеют в 3.12. Интересно, что помимо KVM одним из основных потребителей нового механизма может стать Android. Специфика работы мобильного Linux такова, что там постоянно отключаются и включаются заново в работу ядра микропроцессора (энергосбережение). Т.е. в очередной раз разработчики "больших" систем помогают маленьким.

Инженер Parallels, Pavel Emelyanov, выпустил CRIU версии 0.8 (в Fedora уже собрана).

Участник Fedora, инженер Red Hat, Karel Zak, выпустил util-linux версии 2.24.

Наши друзья в Eucaliptus выпустили версию 3.4 своей одноименной облачной системы. Из новых фич релиза, хотелось бы отметить интеграцию с Riak CS.

Инженер Red Hat, Jim Meyering, объявил о выходе grep 2.15. В этом релизе особенно хочется отметить опциональное использование JIT-компилятора из PCRE, что сильно ускорит работу.

Maksim Melnikau, инженер Wargaming, побывал на LinuxCon Europe 2013 и изложил запомнившееся в виде презентации.

systemd effectively mandatory now due to GNOME

Конечно, это только проверка перед финальным внедрением, и завтра systemd по умолчанию в Debian не появится - вон, в Arch Linux, тоже не сразу внедряли. Но теперь уже понятно, что появление systemd по умолчанию в Debian, это лишь вопрос времени, и большинством мэйнтейнеров Debian выбор сделан правильный. Хотелось бы отметить последовательно отстаивающих свою позицию разработчиков GNOME, которые не соглашались с заменой компонентов systemd на наколеночные аналоги, написанные для использования альтернативных init-систем. На очереди переход на systemd проектов KDE и Enlightenment, что немного простимулирует сомневающихся.

Ну и разумеется у недовольных systemd всегда остается выбор - у них будет возможность переключиться на fvwm, xmonad, twm и другие удобные window-менеджеры. Дольше всех, что уже понятно, без systemd продержится Ubuntu, но т.к. они целиком базируются на GNOME, и уже давно массово копипастят куски systemd, то мы уверены, что у немногочисленных мэйнтейнеров Canonical уже давно есть навязчивые мысли о том, как сэкономить время и другие ресурсы, отказавшись от Upstart. К сожалению, участники коммьюнити Ubuntu и инженеры Canonical не допускаются до обсуждения вопросов такого уровня - за них единолично решает Mark Shuttleworth.