# Направления работ в 5-STABLE

The &os; Release Engineering Team
$FreeBSD$
2003
The &os; Release Engineering Team
&tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.opengroup; &tm-attrib.general;

## Введение и информация общего характера

В январе 2003 года, после примерно трёх лет работы, была выпущена &os; 5.0. Такие её возможности, как технология GEOM, мандантный контроль доступа, ACPI, поддержка архитектур &sparc64; и ia64, работа с мгновенными копиями UFS, фоновая проверка целостности файловой системы и 64-разрядная размерность узлов файловой системы делают эту операционную систему привлекательной как для корпоративного, так и персонального использования. Однако работа над некоторыми важными возможностями ещё не завершена. Программная основа для высокоточной блокировки и вытесняемости задач в ядре уже имеется, однако предстоит сделать ещё больше. Производительность и стабильность по сравнению с &os; 4.X несколько снизилась, однако эти характеристики должны быть восстановлены и даже улучшены.

Это несколько напоминает ситуацию, с которой &os; сталкивалась в линейке 3.X. Работа над 3-CURRENT затягивалась до бесконечности, и наконец было принято решение просто выпустить её, а доработать позже. Такое решение привело к тому, что качество релизов 3.0 и 3.1 не могло удовлетворить большинство пользователей, и так было до версии 3.2, когда линейка была признана стабильной. Хуже того, ветка &t.releng.3; была создана на основе релиза 3.0. а ветка &t.releng.head; должна была вести к 4-CURRENT. В результате ветки &t.releng.head; и &t.releng.3; стали сильно отличаться, что значительно осложнило поддержку ветки &t.releng.3;. &os; 2.2.8 была оставлена как последняя версия &os;, подходящая для продуктивной эксплуатации.

Нашей задачей является недопущение повторения такого сценария во &os; 5.x. Откладывание ветки &t.releng.5; до момента, когда она станет стабильной и достигнет качества продукта, готового к реальной эксплуатации, обеспечит будущую поддержку этой ОС и объективную причину перехода с версии 4.X, Для этого мы должны определить слабые места и наметить способы их устранения. В этом документе описаны те моменты, которые мы, как группа по подготовке релизов, считаем значительными и те вопросы, которые должны быть решены до создания ветки &t.releng.5;. Здесь не определяются все аспекты работы над &os;, и мы готовы к дальнейшему обсуждению. Ничего из того, что написано далее, не является инсинуациями против какой бы то ни было персоны или группы, целью не является упрощение никакой сделанной кем-то работы. Однако имеются некоторые важные вопросы, которые требуют решительных и беспристрастных действий.

## Основные вопросы

Успех линейки 5.X зависит от возможности предоставить высокоточное управление потоками выполнения и повторяемость вызовов в ядре (что известно как SMPng), а также поддержки на уровне ядра POSIX-потоков выполнения пользовательского уровня, не жертвуя при этом общей стабильностью или производительностью системы.

### SMPng

Работам над SMPng и блокировками на уровне ядра уделяется самое большое внимание для 5.X. На текущий момент было выпущено несколько версий системы с глобальными семафорами на всё ядро, известными как Giant. Страница о состоянии работ над SMP по адресу содержит исчерпывающую информацию об общем состоянии SMPng. Информация по конкретно работам над SMPng в драйверах устройств может быть найдена на странице . В целом:

- VM: Функция ядра malloc изолирована и освобождена от Giant. Распределитель зон UMA также не использует Giant. Изоляция vm_object находится в работе и является важным шагом в исключении Giant из работы с буферами/кэшем. Изоляция pmap ещё не реализовывалась.

- GEOM: Уровень блоков GEOM был разработан с учётом работы без Giant и он позволяет работать модулям GEOM и низлежащим драйверам блочных устройств без Giant. На данный момент только драйверы &man.ata.4; и &man.aac.4; разделены и работают без Giant. Работа над остальными драйверами блочных устройств ведётся. Изоляция CAM-подсистемы требует отказа от использования Giant практически во всех драйверах SCSI; работа над этим ещё не начиналась.

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

- Сеть: Работа по переводу на изоляцию сетевого стека была начата заново. Изначально целями были таблицы маршрутизации, ARP, функции моста, IPFW, Fast-Forward, TCP, UDP, IP, Fast IPSEC и уровни интерфейсов, а также некоторые драйверы устройств Ethernet. Позже были поставлены цели по изоляции уровней сокетов, IPv6 и других сетевых протоколов. Основной задачей этой работы является восстановление производительности, достигнутой во &os; 4.X. Затраты на переключение контекстов на ithreads и netisr в драйверах устройств всё ещё сильно влияют на производительность.

- VFS: Начата предварительная подготовка.

- буфер/кэш: Закончена начальная работа по изоляции буферов.

- Proc: Начальное изоляция proc уже есть, во &os; 5.2 ожидается ещё больший прогресс.

- CAM: На уровне CAM SCSI значительной работы не проделано.

- Newbus: была проделана некоторая работа по изоляции структуры device_t.

- Pipes: завершено

- Файловые дескрипторы: завершено.

- Process accounting: jails, credentials, MAC labels и планировщик не используют Giant.

- Технология MAC: завершено

- Timekeeping: завершено

- kernel encryption: криптографические драйверы и ядро технологии &man.crypto.4; не используют Giant. KAME IPsec не отделяются.

- Аудио-подсистема: завершено, однако остаются проблемы с обратным порядком изоляций.

- вытесняемость ядра: включена вытесняемость для потоков выполнения прерываний. Однако несогласованность из-за того, что Giant используется в большинстве кода ядра и подпрограммах обработки прерываний драйверов устройств, вызывает множество лишних переключений контекста и может на самом деле сказаться на производительности. Ведётся работа по выяснению того, как сделать вытесняемость условной.

### Задержки на прерывания и их обработка

В SMPng появилась концепция выделенных потоков выполнения ядра, известных под названием ithreads, для обслуживания прерываний. С ними подпрограммы обслуживания прерываний от устройств могут создавать блокировки для выставления семафоров, выделения памяти и так далее. Хотя это облегчает написание драйверов, при этом понижается реактивность системы из-за того, что для обслуживания ithread должно быть выполнено полное переключение контекста процесса. Это усугубляется значительным использованием ядром семафора Giant, и часто приводит к множеству пауз и переключений контекстов для обслуживания прерывания. Драйверы, которые зарегистрировали свои прерывания как INTR_MPSAFE, меньше всего почувствуют этот эффект, однако потери на переключение контекста останутся. Подпрограммы обслуживания прерываний, зарегистрированные как INTR_FAST, работают непосредственно из контекста прерывания, и на них вовсе не сказываются эти проблемы. Однако указание свойства INTR_FAST заставляет линию прерываний стать эксклюзивной; её нельзя использовать одновременно с чем-то. Большое количество совместно используемых прерываний на PC-системах делает это нежелательным.

Для помощи в решении этой проблемы были предложены несколько идей:

- Возможно, особый случай облегчённых ithread. При этом может, придётся уменьшить количество сохраняемых данных контекста для ithread, заимствовать стек из другого kthread и/или создавать новый быстрый способ обхода подпрограммы mi_switch().

- Можно ввести новую модель обработки прерываний, которая позволит драйверам регистрировать 'фильтр прерываний' вместе с обычной процедурой обработки. Это будет похоже на используемую сейчас в Mac OS X модель. Процедуры фильтрации прерываний позволят драйверу определять, должен ли он участвовать в обработке прерывания, позволят ему подавлять источник прерываний и, возможно, определять и планировать действия по его обработке. Она будет работать в том же самом контексте, что и низкоуровневая процедура обслуживания прерывания, так что паузы будут жёстко запрещены. Если требуются действия, которые приводят к паузам или блокировке на долгий период, фильтр будут сигнализировать об этом вызывающей стороне, что должна быть запланирована обычная ithread-процедура.

### Потоки приложений, поддерживаемые ядром

В процессе работы над FreeBSD 5.1 пакет KSE был доведён до весьма пригодного к использованию состояния. Также появился THR, альтернативный пакет по управлению потоками выполнения, основанный на некоторых примитивах KSE уровня ядра, но реализующий исключительно подход планирования задач 1:1, также находится в подобном экспериментальном, но пригодном к работе состоянии. Пользователи могут менять эти две библиотеки со старой библиотекой libc_r посредством перекомпоновки своих приложений или при помощи новой техники libmap компоновщика времени выполнения. Такой значительный прогресс в ходе работ должен привести к их завершению до момента появления ветки &t.releng.5;, так что пакет libc_r может оказаться ненужным.

- Компоненты уровня ядра и пользовательского уровня для KSE и THR должны быть созданы для все платформ уровня Tier-1. Решение о том, какой пакет реализации потоков выполнения будет использоваться по умолчанию, будет, скорее всего, приниматься для каждой платформы отдельно, в зависимости от стабильности и завершённости каждого пакета.

  #### Состояние KSE

  Платформа | Уровень ядро | Пользовательский уровень | Работает?
  --- | --- | --- | ---
  i386 | ДА | ДА | ДА
  alpha | НЕТ | ДА | НЕТ
  sparc64 | ДА | НЕТ | НЕТ
  ia64 | ДА | ДА | ДА
  amd64 | ДА | ДА | ДА

  #### Состояние THR

  Платформа | Уровень ядра | Пользовательский уровень | Работает?
  --- | --- | --- | ---
  i386 | ДА | ДА | ДА
  alpha | ДА | ДА | ДА
  sparc64 | ДА | ДА | НЕТ
  ia64 | ДА | ДА | ДА
  amd64 | НЕТ | НЕТ | НЕТ

- KSE должен пройти набор тестов ACE на всех платформах статуса Tier-1. Чтобы убедиться в том, что все библиотеки на самом деле работоспособны, необходимо выполнить дополнительное тестирование на реальных задачах. Как минимум, должны быть протестированы следующие пакеты:

  - OpenOffice

  - KDE Desktop

  - Apache 2.x

  - BIND 9.2.x

  - MySQL

  - &java; 1.4.x

## Требования к 5-STABLE

Ветка &t.releng.5 должна дать пользователям такую же стабильность и производительность, которая сейчас достигнута в ветке &t.releng.4;. Хотя целью работ над SMPng является значительное повышение производительности по сравнению с имеющейся в &t.releng.4; и родственных вариантах BSD, получение хотя бы ранее достигнутой производительности является самой важной задачей. Ветка должна быть достаточно готовой, чтобы избежать изменений в ABI и API, но позволять решать потенциальные проблемы.

### Стабильность ABI/API/инфраструктуры

Инфраструктура должна быть достаточно подготовленной и устоявшейся, чтобы исправления из ветки &t.releng.head; можно было легко и безболезненно переносить в &t.releng.5;. Кроме того, мы должны определиться, какие подсистемы должны работать с блокировками при переходе к 5-STABLE.

- KSE: И компоненты уровня ядра, и компоненты пользовательского уровня должны достичь одинакового уровня функциональности во всех платформах уровня Tier-1 в UP и SMP конфигурациях. Определение того, что является платформами ранга Tier-1, можно найти в . При приближении к выпуску ветки &t.releng.5; должно продолжиться тестирование на пакете тестов ACE. В KSE не должно допускаться уменьшение функциональности для будущей программы сертификации &java;. Распространённые прикладные и серверные приложения должны работать в KSE без проблем. Должна быть определена политика относительно того, на каких платформах KSE будет использоваться в качестве стандартного пакета для организации потоков выполнения, как пользователь может переключаться между такими пакетами и как пакеты сторонних разработчиков должны отслеживать такие изменения.

- интерфейс и драйверы busdma: такие архитектуры, как PAE/&i386; и sparc64, в которых отсутствует прямое отображение адресного пространства хоста в адресное пространство плат расширения, требуют исключения функции vtophys() и ей подобных. Интерфейс busdma был создал для решения именно этой проблемы, однако многие драйверы его ещё не используют. Проект busdma на странице отслеживает ход этих работ и это можно использовать для определения того, какие драйверы должны быть преобразованы для &t.releng.5;, а какие можно оставить. В дереве исходных текстов &os; не должно быть новых драйверов для устройств хранения или сетевых драйверов. Исключения для других классов драйверов нужно согласовывать в открытом обсуждении.

- распределение ресурсов PCI: соответствие спецификации PC2003 требует, что системы x86 не конфигурировали устройства PCI из системной BIOS, оставляя эту задачу исключительно ОС. Во &os; должна появиться возможность управления и распределения ресурсов памяти PCI своими силами. Реализация этого должна принять во внимание существование требований cardbus, PCI-HotPlug и доков для лэптопов. Эта возможность станет ещё более критичной в течение жизни ветки &t.releng.5;, и поэтому является требованием к выпуску &t.releng.5;.

### Производительность

Производительность зависит от хода работ над инфраструктурой SMPng и в следующих областях:

- Устройства хранения: Технология GEOM позволяет драйверам устройств хранения работать без использования Giant. Все драйверы, которые взаимодействуют напрямую с GEOM (в противоположность тем, что находятся ниже уровня CAM или другого промежуточного слоя), должны изолироваться и избавляться от использования Giant как в части strategy, так и completion. Их обработчики прерываний также должны избавиться от Giant.

- Сеть: уровни в работе IPv4, лежащие ниже уровня сокетов, должны быть изолированными и не использовать Giant. Сюда включается протокол, маршрутизация, организация моста, фильтрация и аппаратный уровень. Скидки должны быть сделаны для протоколов, которые не изолируются, особенно IPv6. Для достижения стабильности, корректности и производительности также необходимо выполнить тестирование.

- Прерывания и переключение контекстов: Как обсуждалось выше, задержки в прерываниях и переключениях контекстов имеют большое влияние на производительность. Переключение контекстов для ithread и kthread на всех платформах должно быть улучшено. Должна быть исследована и реализована возможность создания новой модели обработки прерываний, которая позволяет выполнять более быструю и гибкую обработку как обычных, так и MSI прерываний.

### Стандартные тесты и тестирование производительности

Для выявления проблем с производительностью и борьбы с её ухудшением необходимо информативное и надёжное проведение тестов. Вскоре должна быть сформирована группа производительности из людей и ресурсов для формулирования, разработки и выполнения стандартных тестов производительности. Сравнения должны делаться как с &os; 4.X, так и Linux 2.4/2.6. Предполагаются следующие тесты:

- классический worldstone

- webstone: `www/webstone`

- Fstress:

- ApacheBench: `www/p5-ApacheBench`

- netperf: `benchmarks/netperf`

- Web Polygraph: Замечание: пока не компилируется с gcc 3.x.

### Особые возможности:

- NEWCARD/OLDCARD: Подсистема NEWCARD во &os; 5.0 сделана используемой по умолчанию. К сожалению, в ней отсутствует поддержка для не-Cardbus мостов и на некоторых лэптопах она не работает из-за проблем с маршрутизацией прерываний. Классическая реализации поддержки 16-битных мостов, OLDCARD, продолжает существовать и может быть вкомпилирована, однако это неудобно для пользователей старых лэптопов. Если от OLDCARD для &t.releng.5; нельзя будет полностью отказаться, то должны быть сделаны шаги, которые позволят пользователям легко устанавливать ядро с поддержкой OLDCARD. Должна быть написана документация в помощь пользователям по переходу от OLDCARD к NEWCARD и от &man.pccardd.8; к &man.devd.8;. Функциональность по управлению электропитанием и dumpcis утилиты &man.pccardc.8; должна быть усилена поддержкой NEWCARD, а также возможностью подгружать информацию о нестандартном оборудовании CIS. Основной объём этих функций может быть интегрирован в &man.devd.8; и &man.devctl.4;.

- Новый планировщик задач: Он уже готов, и пользователи могут выбирать между классическим планировщиком 44BSD и новым планировщиком ULE. В ветке &t.releng.5; должен быть планировщик, имеющий привязку к процессору, поддержку HyperThreading и KSE, а также отсутствие снижения производительности или времени реакции системы.

- GDB: GDB в основном системном наборе должен работать со sparc64, а также понимать потоки KSE. Уже имеется GDB 5.3, сообщается, что он решает проблемы со sparc64.

### Документация:

- Справочные страницы, Руководство и FAQ должны быть очищены от содержимого, специфичного для &os; 4.X, то есть весь текст должен подходить и для &os; 5.X. Больше всего работы здесь предстоит сделать в разделе Руководства по установке.

- Документация к релизу должна быть полной и точной для всех архитектур уровня Tier-1. Особого внимания требуют замечания по оборудованию и инструкции по установке.

## Календарный план

Из-за сложности стоящих задач первоначальный план выпуска &os; 5.2 и создания ветки &t.releng.5; в сентябре 2003 года был сдвинут. Новый календарный план выглядит так:

- 18 ноября 2003: 5.2-BETA, общая заморозка кода

- 6 декабря 2003: 5.2-RC1, создание ветки &t.releng.5.2;

- 9 декабря 2003: 5.2-RC2

- 16 декабря 2003: 5.2-RELEASE

- 1 марта 2004: 5.3-BETA, общая заморозка кода

- 15 марта 2004: 5.3-RC1, создание веток &t.releng.5; и &t.releng.5.3;

- 22 марта 2004: 5.3-RC2

- 29 марта 2004: 5.3-RELEASE

## Направление работ после &t.releng.5;

Как это происходит и с другими ветками -STABLE, в основном работа над ней должна заключаться в исправлении ошибок и последовательном улучшении. Как обычно, всё должно проходить проверку в ветке &t.releng.head;, а затем внимательно переноситься в &t.releng.5;. Как и раньше, новые драйверы устройств, дополнительные возможности и тому подобные разработки приветствуются в этой ветке только после проверки в &t.releng.head;.

Дальнейшая изоляция SMPng будет разделена на две категории, драйвер и подсистема. Единственной подсистемой, которая будет достаточно изолированной к выходу &t.releng.5;, будет GEOM, так что постепенное изолирование драйверов устройств под её управлением является достойной задачей этой ветки. Полная изоляция подсистемы будет выполнена и опробована в ветке &t.releng.head; до того, как будет принято решение о переносе её в ветку &t.releng.5;.