Далее — перевод статьи с сайта IBM. Вряд ли вы узнаете что-то принципиально новое из неё. Данную статью хорошо использовать как отправную точку для чтения об интересных или ранее неизвестных вам особенностях Линукс. Часть ссылок я привёл в тексте статьи курсивом, часть можно увидеть в конце оригинальной статьи. Мои пояснения или комментарии выделены курсивом.
В релизы ядра Линукс версий 3.3 и 3.4 вошло впечатляющее количество улучшений. Однако эти релизы не просто развитие ядра, но зловещий рубеж на пути этого развития.
Релиз версии 3.3 — первый релиз ядра линукс, объём которого превысил 15 миллионов строк (пусть даже по откровенно кривому способу измерения). Если вы вычтете изменяему, непостоянную часть кода (различные драйвера, платформозависимый код и различные утилиты), число строк падает немного ниже 4 миллионов — левиафан собственной персоной.
Зловещее в этом рубеже и скорость, с которой растёт ядро (пятидесятипроцентный рост с 2008 года), и то что этот рост может негативно повлиять на ядро (как с точки зрения производительности, так и с точки зрения возможностей ядра). Возможности и производительность обычно не измеряют «попатчево», так что в ядро вполне может попасть баг, который будет сохраняться некоторое время (например, проблема со PCIe ASPM, которая была в ядре почти год, но была исправлена в версии 3.3 Описание www.pcworld.com/businesscenter/article/244277/new_kernel_patch_slashes_linuxs_power_appetite.html и патч lkml.org/lkml/2011/11/10/467)
Менее чем за 21 год линукс вырос с 10000 строк кода до более чем 15 миллионов. Кроме того, большая часть этого кода находится в поддереве драйверов, а сложность ядра увеличивается с его размерами. Рано или поздно, это расширение должно вылиться в изменения, которые сделают ядро более простым. Как с точки зрения кода, так и с точки зрения поддержки этого кода.
Как показано на иллюстрации номер 1, ядро быстро вырослос момента релиза 2.4 в 2001 году (с 3 377 902 строк до 15 998 651 строкив 2012). В течение этого срока, каждый год в ядро добавлялось около миллиона строк. Это ошеломляющая иллюстрация и должна внушать страх каждому разработчику софта.
Цитируют слова самого Торвальдса, о его озабоченности поддержкой ядра, по мере его роста. С 4 миллионами строк кода, которые составляют саму суть ядра, текущая система управления исходными кодами ядра может потребовать улучшения.
Интеграция андроида.
Самая большая новость ядра 3.3 — включение в основную ветку ядра Google Android. Эта интеграция продолжится в ядре 3.4, но уже сейчас в ядре достаточно кода от андроида, чтобы поддерживалась загрузка андроида в user-space'е. Ядро андроида — форк ядра Линукс, с несколькими особенностями. Эти особенности введены для эффективной работы мобильных устройств, которые сильно ограничены в доступном питании. Кроме того, в андроиде основной упор делается на архитектуру ARM, хотя поддержка x86 тоже присутствует (например, для проекта Google TV).
Проблемы взаимодейтсвия между мейнтейнерами Линукса и Гуглом привели к тому, что Андроид разрабатывался несколько лет отдельно. Зимой 2011-2012 года был создан проект Android Mainlining, чья цель — интегрировать драйвера и новые функции ядра Андроида в основное дерево исходников Линукса. Проделанная работа была представлена широкой публике в ядре 3.3 и будет продолжена в последующих релизах.
Андроид внёс несколько улучшений в Линукс, которые были необходимы, чтобы быть конкурентноспособным в мобильной среде. В качестве примера можно привести быстрые механизмы межпроцессорного взаимодействия (Fast IPC), улучшенные механизмы управления памятью и решение проблемы управления большими непрерывными областями памяти.
Binder — драйвер, который стал ответом Андроида стандартным механизмам IPC. Разработчики Андроида запросто могли использовать существующий код, однако разработка Binder'а предоставила несколько юникальных «фишек», которые раньше были недоступны (передача сообщений без копирования и передача «мандатов». Подробнее можно ознакомиться по ссылке lwn.net/Articles/466304/ ). В Андроиде приложения никогда не выходят привычным образом, они работают до тех пор, пока ядро не завершит их. Для оптимизации использования памяти существует механизм под названием Shrinker. Приложения регистрируют функцию, которая при вызове минимизирует количество используемой ими памяти. Ядро вызывает эти функции, когда ему начинает не хватать памяти. Другой механизм, который перекочевал из Андроида — Pmem. Этот механизм позволяет выделять физически непрерывный участок памяти. Подобная функция используется, например, при работе фотокамеры в телефонах. В рамках этого механизма существует API в пространстве пользователя, с помощью которого можно получить от системы непрерывный участок памяти. Кроме этих механизмов, из Андроида были перенесены и другие функции, специфичные для мобильных устройств.
Некоторые механизмы ещё не попали в ядро. Например, wakelocks — механизм управления питанием, который позволяет отдельным программам не давать системе входить в состояние пониженного энергопотребления (например, если идёт апдейт). Это, конечно, не помешает Андроиду загрузиться, однако может привести к быстрому пожиранию батареи.
Слияние Андроида с основной веткой разработки ядра Линукс — ещё одна иллюстрация гибкости Линукса. От встроенных и мобильных систем, до крупнейших в мире мейнфреймов и суперкомьютеров: Линукс прижился везде. И Линукс продолжает своё развитие как универсальная система на более чем 300 миллионах мобильных устройств.
Open vSwitch
Линукс продолжает быть самой популярной платформой виртуализации. Линукс не только операционная система мирового уровня, но так же и гипервизор мирового уровня. Внесение Open vSwitch в основную ветку ядра подтверждает этот статус для тех пользователей, который используют линукс как платформу виртуализации и предоставляют услуги IaaS на линуксе.
Виртуальный коммутатор это не что иное как программная реализация аппаратного коммутатора. Напомню на всякий случай, что платформа виртуализации (в том виде, как сделано в KVM или Xen) позволяет вам запускать несколько копий операционных систем (в роли виртуальных машин) на гипервизоре, который управление доступом к физическим ресурсам машины. Введение виртуального коммутатора расширяет эту абстракцию, вводя новые формы сетевой инфраструктуры. Виртуальный коммутатор предоставляет эффективные средства для виртуальных машин для взаимодействия друг с другом по виртуальной сети. Open vSwitch расширяет функции виртуального коммутатора, позволяя объединять виртуальные сети нескольких гипервизоров. Таким образом, виртуальные машины могут взаимодействовать через виртуальную сеть с машинами, находящимися на других гипервизорах.
Внутри Open vSwitch реализован широкий набор функций для виртуализации сети. Среди этих функций: QoS, vlan'ы, фильтрация и изоляция трафика, а так же набор протоколов для мониторинга и управления (такие как OpenFlow и NetFlow). Не смотря на то, что в линуксе уже была реализация виртуальных коммутаторов (Linux Bridge), Open vSwitch намного более функциональное решение и следованительно — желанное дополнение.
Изменения файловых систем.
В релизе 3.3 внесены некоторые изменения в ряд файловых систем, которые будут актуальны как для пользователей, так и для разработчиков. Для пользователей, это онлайн изменение размеров ext4 томов, по средствам контроля операций ввода вывода (вызов ioctl с флагом «EXT4_IOC_RESIZE_FS»). Под «онлайн» понимает то, что система остаётся в рабочем состоянии. Кроме того, теперь вся операция изменения размера производится в ядре, что ускоряет её.
Был переписан мезанизм балансировку для btrfs. Теперь он поддерживает приостановку и возобновление работы. Этот механизм используется для изменения структуры метаднных в таких случаях, например, как добавление нового жёсткого диска. Улучшение btrfs продолжилось в релизе 3.4, в котором была представлена утилита восстановления данных с повреждённых томов (btrfs-restore). Кроме того, в релиз 3.4 были внесены некоторые изменения, которые улучшили быстродействие и обработку ошибок в btrfs: вместо некоторых сообщениях об ошибках, теперь элегатная обработка этих самых ошибок. До релиза 3.4 btrfs плохо показывала себя в качестве файловой системы внутри виртуальной машины. Причиной этому была реализация механизма copy-on-write (CoW). Была проведена доработка, чтобы излечить этот недостаток.
Реализация RAID так же была изменена. Теперь программная реализация RAID поддерживает «горячую замену»: данные с одного тома, могут быть перенесены на другой том, при этом первый позднее можно удалить из массива без потери данных. Управление этой функцией осуществляется через всем знакомый mdadm.
И наконец в релизе 3.4 добавленена поддержка файловой системы QNX4 (пока в режиме «только чтение»).
Разработчики получили возможность вносить ошибки в работу сетевой файловой системы (NFS), чтобы проверять возможность клиента восстанавливаться после этих ошибок (механизм работает через sysfs). Для разработчиков brtfs была добавлена утилита проверки целостности файловой системы, которая может быть использована для обнаружения неверных запросов на запись, что позволит быстрее исправлять проблемы.
Улучшения в работе сети.
Так же в релиз 3.3 было внесено несколько передовых изменений.
Для низколатентных сред (такие как суперкомпьютерные вычисления) была введена возможность предоставлять доступ к устройствам по протоколу SCSI RDMA (очень кратко можно прочесть тут: ru.wikipedia.org/wiki/InfiniBand ). SCSI RDMA это протокол, который позволяет вам использовать RDMA как транспорт для блочных устройств. RDMA поддерживается InfiniBand'ом и достаточно распространён в среде суперкомпьютерных вычислений.
Был модифицирован плаировщик пакетов RED (Random Early Detection). Был изменён алгоритм работы в соответсвии с предложениями Салли Флойда (Sally Floyd), Рамакришны Гаммади (Ramakrishna Gummadi) и Скотта Шенкера (Scott Shenker). Новый планировщик получил название ARED (Adaptive RED, принято переводить калькой «адаптивный» ;). RED отслеживает средний размер очереди и отбрасываемых пакетов, основываясь на статистической вероятности. При пустой очереди, все пакеты принимаются. При заполненности очереди выше порогового значения, почти все пакеты отбрасываются. ARED решает в каждом отдельном случае, сделать ли RED более или менее агрессивным, основываясь на наблюдениях за средней длиной очереди. Больше об ARED можно узнать из материалов по ссылке: icir.org/floyd/papers/adaptiveRed.pdf .
Так же в релиз 3.3 была добавлена новая реализация для замены устаревшего драйвера бондинга. Группировка нескольких физических интерфейсов в один виртуальный, позволяет создавать интерфейсы с большшей надёжность и пропускной способностью (в соответствии, например, с протоколом 802.1AX). На текущий момент поодерживается два режима работы нового механизма: простое распределение пакетов по правилу round-robin или active-backup. В первом случае пакеты шлются по очереди с каждого из физических интерфейсов. Во втором случае данные передаются по одному физическому интерфейсу и при его «падении» — по запасному.
Среди большого количество сделанных изменений, можно так же выделить интересное дополнение к реализации cgroups: добавлена реализация ограничений буферов для ТСР. cgroups используются различными способами. В том числе — для ограничения ресурсов виртуальных машин. После этого изменения стала доступна более тонка настройка использования системной памяти, а следовательно — более детальное управление системой в целом.
Другие интересные изменения
В релиз ядра 3.3 так же попали изменения не связанные с файловыми системами или сетью. Была добавлена поддержка новой архитектуры: в основную ветку ядра внесёд код проекта, по поддержке процесса C6x от Texas Instruments. С6х это процессоры VLIW архитектуры с одним или несколькими ядрами. Эти процессоры не поддерживают такие функции как SMP и когерентность кэша. Кроме того, в них нет блока управления памятью (MMU). Несмотря на эти недостатки, процессоры серии С6х имеют широкий набор периферии и дополнительных блоков, выполненных непосредственно на чипе (например, для быстрого преобразования Фурье).
В релиз 3.4 включена поддержка последних GPU, таких как Nvidia Kepler и последние Radeon'ы и Trinity от AMD
В архитектуре ARM теперь поддерживается расширение LPAE (PAE для работы с памятью до 1ТБ. Подробнее, например, в пдф со страницы www.linux-arm.info/index.php/130-linux-support-for-arm-lpae ). Кроме того, включена поддержка однокристальных систем от Nvidia (Tegra 3). Эти изменения позволяют процессорам ARM конкурировать с процессорами от Интел в сегменте серверов с низким энергопотреблением. Были сделаны ряд изменений в реализацию работы AMD IOMMU, которые улучшили управление страницами памяти изменяемого размера и безопасность, с точки зрения доступа устройств к памяти. Виртуальные фукнции ввода-вывода расширяют возможности KVM по предоставлению устройств виртуальным машинам.Кроме того архитектура S390 была доработана для поддержки до 64ТБ оперативной памяти (против 1 ТБ в предыдущих версиях)
Блок мониторинга производительности получил виртуальный интерфейс для KVM. ТАким образом, теперь гостевые ОС могут отслеживать производительность на своей платформе. В рамках этого мониторинга доступны такие метрики, как «количество выполненых инструкций (retired instructions), попадания и промахи по кэшу, а так же успешность предсказания переходов. Другим полезным нововведением является функция „безопасного сброса“. Эта функция позволяет не просто пометить сектор в запросе как свободный, но полностью его удалить.
Различные драйвера ввода/вывода (blk, net, balloon и console) теперь поддерживают ACPI и S4 sleep state, что означает, что теперь гостевые ВМ на Xen'е можно гибернировать.
Для отладки сложных проблем с повреждением памяти была добавлена новая опция конфигурации CONFIG_DEBUG_PAGEALLOC. При её включении будет отслеживаться доступ процессора к неаллоцированным страницам. Включение этой опции, естественно, приведёт к снижению производительности.
Взгляд в будущее.
Линукс продолжает развиваться и в то время как релиз 3.4 уже вышел, релиз-кандидат 3.5 уже почти готов к выпуску в августе 2012.
В следующем релизе нас так же ждёт много нового: в btrfs улучшен механизм обратной записи, в ext4 добавлена возможность хранить контрольные суммы, для определения манипуляций с данными. Линукс, возможно, скоро будет поддерживать предоставление доступа к своим устройствам по протоколу SCSI по FireWire или SCSI по USB. Так же обещают включить поддержку обследования в user-space и использование SystemTap для анализа полученных данных. В будущем нас ждёт ещё много интересного, по мере развития ядра.
Автор: oxpa
