diff --git a/ru_RU.KOI8-R/articles/5-roadmap/article.sgml b/ru_RU.KOI8-R/articles/5-roadmap/article.sgml new file mode 100644 index 0000000000..91103befad --- /dev/null +++ b/ru_RU.KOI8-R/articles/5-roadmap/article.sgml @@ -0,0 +1,759 @@ + + + +%man; + + +%freebsd; + + +%authors; + + +%teams; + + +%mailing-lists; + + +%trademarks; + +RELENG_3"> +RELENG_4"> +RELENG_5"> +RELENG_5_1"> +RELENG_5_2"> +RELENG_5_3"> +HEAD"> + +]> + +
+ + Направления работ в 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;. + +