Copyright © 2003 The FreeBSD Release Engineering Team
$FreeBSD$
В январе 2003 года, после примерно трёх лет работы, была выпущена FreeBSD 5.0. Такие её возможности, как технология GEOM, мандантный контроль доступа, ACPI, поддержка архитектур Sparc64® и ia64, работа с мгновенными копиями UFS, фоновая проверка целостности файловой системы и 64-разрядная размерность узлов файловой системы делают эту операционную систему привлекательной как для корпоративного, так и персонального использования. Однако работа над некоторыми важными возможностями ещё не завершена. Программная основа для высокоточной блокировки и вытесняемости задач в ядре уже имеется, однако предстоит сделать ещё больше. Производительность и стабильность по сравнению с FreeBSD 4.X несколько снизилась, однако эти характеристики должны быть восстановлены и даже улучшены.
Это несколько напоминает ситуацию, с которой FreeBSD сталкивалась в линейке 3.X. Работа над 3-CURRENT затягивалась до бесконечности, и наконец было принято решение ``просто выпустить её'', а доработать позже. Такое решение привело к тому, что качество релизов 3.0 и 3.1 не могло удовлетворить большинство пользователей, и так было до версии 3.2, когда линейка была признана ``стабильной''. Хуже того, ветка RELENG_3 была создана на основе релиза 3.0. а ветка HEAD должна была вести к 4-CURRENT. В результате ветки HEAD и RELENG_3 стали сильно отличаться, что значительно осложнило поддержку ветки RELENG_3. FreeBSD 2.2.8 была оставлена как последняя версия FreeBSD, подходящая для продуктивной эксплуатации.
Нашей задачей является недопущение повторения такого сценария во FreeBSD 5.x. Откладывание ветки RELENG_5 до момента, когда она станет стабильной и достигнет качества продукта, готового к реальной эксплуатации, обеспечит будущую поддержку этой ОС и объективную причину перехода с версии 4.X, Для этого мы должны определить слабые места и наметить способы их устранения. В этом документе описаны те моменты, которые мы, как группа по подготовке релизов, считаем значительными и те вопросы, которые должны быть решены до создания ветки RELENG_5. Здесь не определяются все аспекты работы над FreeBSD, и мы готовы к дальнейшему обсуждению. Ничего из того, что написано далее, не является инсинуациями против какой бы то ни было персоны или группы, целью не является упрощение никакой сделанной кем-то работы. Однако имеются некоторые важные вопросы, которые требуют решительных и беспристрастных действий.
| Next | ||
| Основные вопросы |
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.
Copyright © 2003 The FreeBSD Release Engineering Team
$FreeBSD$
FreeBSD is a registered trademark of Wind River Systems, Inc. This is expected to change soon.
IEEE, POSIX, and 802 are registered trademarks of Institute of Electrical and Electronics Engineers, Inc. in the United States.
Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Sparc, Sparc64, SPARCEngine, and UltraSPARC are trademarks of SPARC International, Inc in the United States and other countries. Products bearing SPARC trademarks are based upon architecture developed by Sun Microsystems, Inc.
Sun, Sun Microsystems, Java, Java Virtual Machine, JavaServer Pages, JDK, JSP, JVM, Netra, Solaris, StarOffice, Sun Blade, Sun Enterprise, Sun Fire, SunOS, and Ultra are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ``™'' or the ``®'' symbol.
В январе 2003 года, после примерно трёх лет работы, была выпущена FreeBSD 5.0. Такие её возможности, как технология GEOM, мандантный контроль доступа, ACPI, поддержка архитектур Sparc64® и ia64, работа с мгновенными копиями UFS, фоновая проверка целостности файловой системы и 64-разрядная размерность узлов файловой системы делают эту операционную систему привлекательной как для корпоративного, так и персонального использования. Однако работа над некоторыми важными возможностями ещё не завершена. Программная основа для высокоточной блокировки и вытесняемости задач в ядре уже имеется, однако предстоит сделать ещё больше. Производительность и стабильность по сравнению с FreeBSD 4.X несколько снизилась, однако эти характеристики должны быть восстановлены и даже улучшены.
Это несколько напоминает ситуацию, с которой FreeBSD сталкивалась в линейке 3.X. Работа над 3-CURRENT затягивалась до бесконечности, и наконец было принято решение ``просто выпустить её'', а доработать позже. Такое решение привело к тому, что качество релизов 3.0 и 3.1 не могло удовлетворить большинство пользователей, и так было до версии 3.2, когда линейка была признана ``стабильной''. Хуже того, ветка RELENG_3 была создана на основе релиза 3.0. а ветка HEAD должна была вести к 4-CURRENT. В результате ветки HEAD и RELENG_3 стали сильно отличаться, что значительно осложнило поддержку ветки RELENG_3. FreeBSD 2.2.8 была оставлена как последняя версия FreeBSD, подходящая для продуктивной эксплуатации.
Нашей задачей является недопущение повторения такого сценария во FreeBSD 5.x. Откладывание ветки RELENG_5 до момента, когда она станет стабильной и достигнет качества продукта, готового к реальной эксплуатации, обеспечит будущую поддержку этой ОС и объективную причину перехода с версии 4.X, Для этого мы должны определить слабые места и наметить способы их устранения. В этом документе описаны те моменты, которые мы, как группа по подготовке релизов, считаем значительными и те вопросы, которые должны быть решены до создания ветки RELENG_5. Здесь не определяются все аспекты работы над FreeBSD, и мы готовы к дальнейшему обсуждению. Ничего из того, что написано далее, не является инсинуациями против какой бы то ни было персоны или группы, целью не является упрощение никакой сделанной кем-то работы. Однако имеются некоторые важные вопросы, которые требуют решительных и беспристрастных действий.
Успех линейки 5.X зависит от возможности предоставить высокоточное управление потоками выполнения и повторяемость вызовов в ядре (что известно как SMPng), а также поддержки на уровне ядра POSIX-потоков выполнения пользовательского уровня, не жертвуя при этом общей стабильностью или производительностью системы.
Работам над SMPng и блокировками на уровне ядра уделяется самое большое внимание для 5.X. На текущий момент было выпущено несколько версий системы с глобальными семафорами на всё ядро, известными как ``Giant''. Страница о состоянии работ над SMP по адресу http://www.FreeBSD.org/smp содержит исчерпывающую информацию об общем состоянии SMPng. Информация по конкретно работам над SMPng в драйверах устройств может быть найдена на странице http://www.FreeBSD.org/projects/busdma. В целом:
VM: Функция ядра malloc изолирована и освобождена от Giant. Распределитель зон UMA также не использует Giant. Изоляция vm_object находится в работе и является важным шагом в исключении Giant из работы с буферами/кэшем. Изоляция pmap ещё не реализовывалась.
GEOM: Уровень блоков GEOM был разработан с учётом работы без Giant и он позволяет работать модулям GEOM и низлежащим драйверам блочных устройств без Giant. На данный момент только драйверы ata(4) и aac(4) разделены и работают без Giant. Работа над остальными драйверами блочных устройств ведётся. Изоляция CAM-подсистемы требует отказа от использования Giant практически во всех драйверах SCSI; работа над этим ещё не начиналась.
Кроме того, в GEOM имеется опасность снижения производительности из-за обработки ею вышестоящих и нижестоящих потоков данных в потоках выполнения ядра. В решении этой проблемы может помочь улучшение и упрощение технологии переключения контекстов выполнения.
Сеть: Работа по переводу на изоляцию сетевого стека была начата заново. Изначально целями были таблицы маршрутизации, ARP, функции моста, IPFW, Fast-Forward, TCP, UDP, IP, Fast IPSEC и уровни интерфейсов, а также некоторые драйверы устройств Ethernet. Позже были поставлены цели по изоляции уровней сокетов, IPv6 и других сетевых протоколов. Основной задачей этой работы является восстановление производительности, достигнутой во FreeBSD 4.X. Затраты на переключение контекстов на ithreads и netisr в драйверах устройств всё ещё сильно влияют на производительность.
VFS: Начата предварительная подготовка.
буфер/кэш: Закончена начальная работа по изоляции буферов.
Proc: Начальное изоляция proc уже есть, во FreeBSD 5.2 ожидается ещё больший прогресс.
CAM: На уровне CAM SCSI значительной работы не проделано.
Newbus: была проделана некоторая работа по изоляции структуры device_t.
Pipes: завершено
Файловые дескрипторы: завершено.
Process accounting: jails, credentials, MAC labels и планировщик не используют Giant.
Технология MAC: завершено
Timekeeping: завершено
kernel encryption: криптографические драйверы и ядро технологии 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 компоновщика времени выполнения. Такой значительный прогресс в ходе работ должен привести к их завершению до момента появления ветки RELENG_5, так что пакет libc_r может оказаться ненужным.
Компоненты уровня ядра и пользовательского уровня для KSE и THR должны быть созданы для все платформ уровня Tier-1. Решение о том, какой пакет реализации потоков выполнения будет использоваться по умолчанию, будет, скорее всего, приниматься для каждой платформы отдельно, в зависимости от стабильности и завершённости каждого пакета.
Table 1. Состояние KSE
| Платформа | Уровень ядро | Пользовательский уровень | Работает? |
|---|---|---|---|
| i386 | ДА | ДА | ДА |
| alpha | НЕТ | ДА | НЕТ |
| sparc64 | ДА | НЕТ | НЕТ |
| ia64 | ДА | ДА | ДА |
| amd64 | ДА | ДА | ДА |
Table 2. Состояние 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
Ветка RELENG_5 должна дать пользователям такую же стабильность и производительность, которая сейчас достигнута в ветке RELENG_4. Хотя целью работ над SMPng является значительное повышение производительности по сравнению с имеющейся в RELENG_4 и родственных вариантах BSD, получение хотя бы ранее достигнутой производительности является самой важной задачей. Ветка должна быть достаточно готовой, чтобы избежать изменений в ABI и API, но позволять решать потенциальные проблемы.
Инфраструктура должна быть достаточно подготовленной и устоявшейся, чтобы исправления из ветки HEAD можно было легко и безболезненно переносить в RELENG_5. Кроме того, мы должны определиться, какие подсистемы должны работать с блокировками при переходе к 5-STABLE.
KSE: И компоненты уровня ядра, и компоненты пользовательского уровня должны достичь одинакового уровня функциональности во всех платформах уровня Tier-1 в UP и SMP конфигурациях. Определение того, что является ``платформами ранга Tier-1'', можно найти в . При приближении к выпуску ветки RELENG_5 должно продолжиться тестирование на пакете тестов ACE. В KSE не должно допускаться уменьшение функциональности для будущей программы сертификации Java. Распространённые прикладные и серверные приложения должны работать в KSE без проблем. Должна быть определена политика относительно того, на каких платформах KSE будет использоваться в качестве стандартного пакета для организации потоков выполнения, как пользователь может переключаться между такими пакетами и как пакеты сторонних разработчиков должны отслеживать такие изменения.
интерфейс и драйверы busdma: такие архитектуры, как PAE/i386™ и sparc64, в которых отсутствует прямое отображение адресного пространства хоста в адресное пространство плат расширения, требуют исключения функции vtophys() и ей подобных. Интерфейс busdma был создал для решения именно этой проблемы, однако многие драйверы его ещё не используют. Проект busdma на странице http://www.FreeBSD.org/projects/busdma отслеживает ход этих работ и это можно использовать для определения того, какие драйверы должны быть преобразованы для RELENG_5, а какие можно оставить. В дереве исходных текстов FreeBSD не должно быть новых драйверов для устройств хранения или сетевых драйверов. Исключения для других классов драйверов нужно согласовывать в открытом обсуждении.
распределение ресурсов PCI: соответствие спецификации PC2003 требует, что системы x86 не конфигурировали устройства PCI из системной BIOS, оставляя эту задачу исключительно ОС. Во FreeBSD должна появиться возможность управления и распределения ресурсов памяти PCI своими силами. Реализация этого должна принять во внимание существование требований cardbus, PCI-HotPlug и доков для лэптопов. Эта возможность станет ещё более критичной в течение жизни ветки RELENG_5, и поэтому является требованием к выпуску RELENG_5.
Производительность зависит от хода работ над инфраструктурой SMPng и в следующих областях:
Устройства хранения: Технология GEOM позволяет драйверам устройств хранения работать без использования Giant. Все драйверы, которые взаимодействуют напрямую с GEOM (в противоположность тем, что находятся ниже уровня CAM или другого промежуточного слоя), должны изолироваться и избавляться от использования Giant как в части strategy, так и completion. Их обработчики прерываний также должны избавиться от Giant.
Сеть: уровни в работе IPv4, лежащие ниже уровня сокетов, должны быть изолированными и не использовать Giant. Сюда включается протокол, маршрутизация, организация моста, фильтрация и аппаратный уровень. Скидки должны быть сделаны для протоколов, которые не изолируются, особенно IPv6. Для достижения стабильности, корректности и производительности также необходимо выполнить тестирование.
Прерывания и переключение контекстов: Как обсуждалось выше, задержки в прерываниях и переключениях контекстов имеют большое влияние на производительность. Переключение контекстов для ithread и kthread на всех платформах должно быть улучшено. Должна быть исследована и реализована возможность создания новой модели обработки прерываний, которая позволяет выполнять более быструю и гибкую обработку как обычных, так и MSI прерываний.
Для выявления проблем с производительностью и борьбы с её ухудшением необходимо информативное и надёжное проведение тестов. Вскоре должна быть сформирована ``группа производительности'' из людей и ресурсов для формулирования, разработки и выполнения стандартных тестов производительности. Сравнения должны делаться как с FreeBSD 4.X, так и Linux 2.4/2.6. Предполагаются следующие тесты:
классический ``worldstone''
webstone: www/webstone
Fstress: http://www.cs.duke.edu/ari/fstress/
ApacheBench: www/p5-ApacheBench
netperf: benchmarks/netperf
Web Polygraph: http://www.web-polygraph.org/ Замечание: пока не компилируется с gcc 3.x.
NEWCARD/OLDCARD: Подсистема NEWCARD во FreeBSD 5.0 сделана используемой по умолчанию. К сожалению, в ней отсутствует поддержка для не-Cardbus мостов и на некоторых лэптопах она не работает из-за проблем с маршрутизацией прерываний. Классическая реализации поддержки 16-битных мостов, OLDCARD, продолжает существовать и может быть вкомпилирована, однако это неудобно для пользователей старых лэптопов. Если от OLDCARD для RELENG_5 нельзя будет полностью отказаться, то должны быть сделаны шаги, которые позволят пользователям легко устанавливать ядро с поддержкой OLDCARD. Должна быть написана документация в помощь пользователям по переходу от OLDCARD к NEWCARD и от pccardd(8) к devd(8). Функциональность по управлению электропитанием и ``dumpcis'' утилиты pccardc(8) должна быть усилена поддержкой NEWCARD, а также возможностью подгружать информацию о нестандартном оборудовании CIS. Основной объём этих функций может быть интегрирован в devd(8) и devctl(4).
Новый планировщик задач: Он уже готов, и пользователи могут выбирать между классическим планировщиком 44BSD и новым планировщиком ULE. В ветке RELENG_5 должен быть планировщик, имеющий привязку к процессору, поддержку HyperThreading и KSE, а также отсутствие снижения производительности или времени реакции системы.
GDB: GDB в основном системном наборе должен работать со sparc64, а также понимать потоки KSE. Уже имеется GDB 5.3, сообщается, что он решает проблемы со sparc64.
Справочные страницы, Руководство и FAQ должны быть очищены от содержимого, специфичного для FreeBSD 4.X, то есть весь текст должен подходить и для FreeBSD 5.X. Больше всего работы здесь предстоит сделать в разделе Руководства по установке.
Документация к релизу должна быть полной и точной для всех архитектур уровня Tier-1. Особого внимания требуют замечания по оборудованию и инструкции по установке.
Из-за сложности стоящих задач первоначальный план выпуска FreeBSD 5.2 и создания ветки RELENG_5 в сентябре 2003 года был сдвинут. Новый календарный план выглядит так:
18 ноября 2003: 5.2-BETA, общая заморозка кода
6 декабря 2003: 5.2-RC1, создание ветки RELENG_5_2
9 декабря 2003: 5.2-RC2
16 декабря 2003: 5.2-RELEASE
1 марта 2004: 5.3-BETA, общая заморозка кода
15 марта 2004: 5.3-RC1, создание веток RELENG_5 и RELENG_5_3
22 марта 2004: 5.3-RC2
29 марта 2004: 5.3-RELEASE
Как это происходит и с другими ветками -STABLE, в основном работа над ней должна заключаться в исправлении ошибок и последовательном улучшении. Как обычно, всё должно проходить проверку в ветке HEAD, а затем внимательно переноситься в RELENG_5. Как и раньше, новые драйверы устройств, дополнительные возможности и тому подобные разработки приветствуются в этой ветке только после проверки в HEAD.
Дальнейшая изоляция SMPng будет разделена на две категории, драйвер и подсистема. Единственной подсистемой, которая будет достаточно изолированной к выходу RELENG_5, будет GEOM, так что постепенное изолирование драйверов устройств под её управлением является достойной задачей этой ветки. Полная изоляция подсистемы будет выполнена и опробована в ветке HEAD до того, как будет принято решение о переносе её в ветку RELENG_5.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.
| Prev | ||
Как это происходит и с другими ветками -STABLE, в основном работа над ней должна заключаться в исправлении ошибок и последовательном улучшении. Как обычно, всё должно проходить проверку в ветке HEAD, а затем внимательно переноситься в RELENG_5. Как и раньше, новые драйверы устройств, дополнительные возможности и тому подобные разработки приветствуются в этой ветке только после проверки в HEAD.
Дальнейшая изоляция SMPng будет разделена на две категории, драйвер и подсистема. Единственной подсистемой, которая будет достаточно изолированной к выходу RELENG_5, будет GEOM, так что постепенное изолирование драйверов устройств под её управлением является достойной задачей этой ветки. Полная изоляция подсистемы будет выполнена и опробована в ветке HEAD до того, как будет принято решение о переносе её в ветку RELENG_5.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.
| Prev | Next | |
Ветка RELENG_5 должна дать пользователям такую же стабильность и производительность, которая сейчас достигнута в ветке RELENG_4. Хотя целью работ над SMPng является значительное повышение производительности по сравнению с имеющейся в RELENG_4 и родственных вариантах BSD, получение хотя бы ранее достигнутой производительности является самой важной задачей. Ветка должна быть достаточно готовой, чтобы избежать изменений в ABI и API, но позволять решать потенциальные проблемы.
Инфраструктура должна быть достаточно подготовленной и устоявшейся, чтобы исправления из ветки HEAD можно было легко и безболезненно переносить в RELENG_5. Кроме того, мы должны определиться, какие подсистемы должны работать с блокировками при переходе к 5-STABLE.
KSE: И компоненты уровня ядра, и компоненты пользовательского уровня должны достичь одинакового уровня функциональности во всех платформах уровня Tier-1 в UP и SMP конфигурациях. Определение того, что является ``платформами ранга Tier-1'', можно найти в . При приближении к выпуску ветки RELENG_5 должно продолжиться тестирование на пакете тестов ACE. В KSE не должно допускаться уменьшение функциональности для будущей программы сертификации Java™. Распространённые прикладные и серверные приложения должны работать в KSE без проблем. Должна быть определена политика относительно того, на каких платформах KSE будет использоваться в качестве стандартного пакета для организации потоков выполнения, как пользователь может переключаться между такими пакетами и как пакеты сторонних разработчиков должны отслеживать такие изменения.
интерфейс и драйверы busdma: такие архитектуры, как PAE/i386™ и sparc64, в которых отсутствует прямое отображение адресного пространства хоста в адресное пространство плат расширения, требуют исключения функции vtophys() и ей подобных. Интерфейс busdma был создал для решения именно этой проблемы, однако многие драйверы его ещё не используют. Проект busdma на странице http://www.FreeBSD.org/projects/busdma отслеживает ход этих работ и это можно использовать для определения того, какие драйверы должны быть преобразованы для RELENG_5, а какие можно оставить. В дереве исходных текстов FreeBSD не должно быть новых драйверов для устройств хранения или сетевых драйверов. Исключения для других классов драйверов нужно согласовывать в открытом обсуждении.
распределение ресурсов PCI: соответствие спецификации PC2003 требует, что системы x86 не конфигурировали устройства PCI из системной BIOS, оставляя эту задачу исключительно ОС. Во FreeBSD должна появиться возможность управления и распределения ресурсов памяти PCI своими силами. Реализация этого должна принять во внимание существование требований cardbus, PCI-HotPlug и доков для лэптопов. Эта возможность станет ещё более критичной в течение жизни ветки RELENG_5, и поэтому является требованием к выпуску RELENG_5.
Производительность зависит от хода работ над инфраструктурой SMPng и в следующих областях:
Устройства хранения: Технология GEOM позволяет драйверам устройств хранения работать без использования Giant. Все драйверы, которые взаимодействуют напрямую с GEOM (в противоположность тем, что находятся ниже уровня CAM или другого промежуточного слоя), должны изолироваться и избавляться от использования Giant как в части strategy, так и completion. Их обработчики прерываний также должны избавиться от Giant.
Сеть: уровни в работе IPv4, лежащие ниже уровня сокетов, должны быть изолированными и не использовать Giant. Сюда включается протокол, маршрутизация, организация моста, фильтрация и аппаратный уровень. Скидки должны быть сделаны для протоколов, которые не изолируются, особенно IPv6. Для достижения стабильности, корректности и производительности также необходимо выполнить тестирование.
Прерывания и переключение контекстов: Как обсуждалось выше, задержки в прерываниях и переключениях контекстов имеют большое влияние на производительность. Переключение контекстов для ithread и kthread на всех платформах должно быть улучшено. Должна быть исследована и реализована возможность создания новой модели обработки прерываний, которая позволяет выполнять более быструю и гибкую обработку как обычных, так и MSI прерываний.
Для выявления проблем с производительностью и борьбы с её ухудшением необходимо информативное и надёжное проведение тестов. Вскоре должна быть сформирована ``группа производительности'' из людей и ресурсов для формулирования, разработки и выполнения стандартных тестов производительности. Сравнения должны делаться как с FreeBSD 4.X, так и Linux 2.4/2.6. Предполагаются следующие тесты:
классический ``worldstone''
webstone: www/webstone
Fstress: http://www.cs.duke.edu/ari/fstress/
ApacheBench: www/p5-ApacheBench
netperf: benchmarks/netperf
Web Polygraph: http://www.web-polygraph.org/ Замечание: пока не компилируется с gcc 3.x.
NEWCARD/OLDCARD: Подсистема NEWCARD во FreeBSD 5.0 сделана используемой по умолчанию. К сожалению, в ней отсутствует поддержка для не-Cardbus мостов и на некоторых лэптопах она не работает из-за проблем с маршрутизацией прерываний. Классическая реализации поддержки 16-битных мостов, OLDCARD, продолжает существовать и может быть вкомпилирована, однако это неудобно для пользователей старых лэптопов. Если от OLDCARD для RELENG_5 нельзя будет полностью отказаться, то должны быть сделаны шаги, которые позволят пользователям легко устанавливать ядро с поддержкой OLDCARD. Должна быть написана документация в помощь пользователям по переходу от OLDCARD к NEWCARD и от pccardd(8) к devd(8). Функциональность по управлению электропитанием и ``dumpcis'' утилиты pccardc(8) должна быть усилена поддержкой NEWCARD, а также возможностью подгружать информацию о нестандартном оборудовании CIS. Основной объём этих функций может быть интегрирован в devd(8) и devctl(4).
Новый планировщик задач: Он уже готов, и пользователи могут выбирать между классическим планировщиком 44BSD и новым планировщиком ULE. В ветке RELENG_5 должен быть планировщик, имеющий привязку к процессору, поддержку HyperThreading и KSE, а также отсутствие снижения производительности или времени реакции системы.
GDB: GDB в основном системном наборе должен работать со sparc64, а также понимать потоки KSE. Уже имеется GDB 5.3, сообщается, что он решает проблемы со sparc64.
Справочные страницы, Руководство и FAQ должны быть очищены от содержимого, специфичного для FreeBSD 4.X, то есть весь текст должен подходить и для FreeBSD 5.X. Больше всего работы здесь предстоит сделать в разделе Руководства по установке.
Документация к релизу должна быть полной и точной для всех архитектур уровня Tier-1. Особого внимания требуют замечания по оборудованию и инструкции по установке.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.
| Prev | Next | |
Успех линейки 5.X зависит от возможности предоставить высокоточное управление потоками выполнения и повторяемость вызовов в ядре (что известно как SMPng), а также поддержки на уровне ядра POSIX-потоков выполнения пользовательского уровня, не жертвуя при этом общей стабильностью или производительностью системы.
Работам над SMPng и блокировками на уровне ядра уделяется самое большое внимание для 5.X. На текущий момент было выпущено несколько версий системы с глобальными семафорами на всё ядро, известными как ``Giant''. Страница о состоянии работ над SMP по адресу http://www.FreeBSD.org/smp содержит исчерпывающую информацию об общем состоянии SMPng. Информация по конкретно работам над SMPng в драйверах устройств может быть найдена на странице http://www.FreeBSD.org/projects/busdma. В целом:
VM: Функция ядра malloc изолирована и освобождена от Giant. Распределитель зон UMA также не использует Giant. Изоляция vm_object находится в работе и является важным шагом в исключении Giant из работы с буферами/кэшем. Изоляция pmap ещё не реализовывалась.
GEOM: Уровень блоков GEOM был разработан с учётом работы без Giant и он позволяет работать модулям GEOM и низлежащим драйверам блочных устройств без Giant. На данный момент только драйверы ata(4) и aac(4) разделены и работают без Giant. Работа над остальными драйверами блочных устройств ведётся. Изоляция CAM-подсистемы требует отказа от использования Giant практически во всех драйверах SCSI; работа над этим ещё не начиналась.
Кроме того, в GEOM имеется опасность снижения производительности из-за обработки ею вышестоящих и нижестоящих потоков данных в потоках выполнения ядра. В решении этой проблемы может помочь улучшение и упрощение технологии переключения контекстов выполнения.
Сеть: Работа по переводу на изоляцию сетевого стека была начата заново. Изначально целями были таблицы маршрутизации, ARP, функции моста, IPFW, Fast-Forward, TCP, UDP, IP, Fast IPSEC и уровни интерфейсов, а также некоторые драйверы устройств Ethernet. Позже были поставлены цели по изоляции уровней сокетов, IPv6 и других сетевых протоколов. Основной задачей этой работы является восстановление производительности, достигнутой во FreeBSD 4.X. Затраты на переключение контекстов на ithreads и netisr в драйверах устройств всё ещё сильно влияют на производительность.
VFS: Начата предварительная подготовка.
буфер/кэш: Закончена начальная работа по изоляции буферов.
Proc: Начальное изоляция proc уже есть, во FreeBSD 5.2 ожидается ещё больший прогресс.
CAM: На уровне CAM SCSI значительной работы не проделано.
Newbus: была проделана некоторая работа по изоляции структуры device_t.
Pipes: завершено
Файловые дескрипторы: завершено.
Process accounting: jails, credentials, MAC labels и планировщик не используют Giant.
Технология MAC: завершено
Timekeeping: завершено
kernel encryption: криптографические драйверы и ядро технологии 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 компоновщика времени выполнения. Такой значительный прогресс в ходе работ должен привести к их завершению до момента появления ветки RELENG_5, так что пакет libc_r может оказаться ненужным.
Компоненты уровня ядра и пользовательского уровня для KSE и THR должны быть созданы для все платформ уровня Tier-1. Решение о том, какой пакет реализации потоков выполнения будет использоваться по умолчанию, будет, скорее всего, приниматься для каждой платформы отдельно, в зависимости от стабильности и завершённости каждого пакета.
Table 1. Состояние KSE
| Платформа | Уровень ядро | Пользовательский уровень | Работает? |
|---|---|---|---|
| i386 | ДА | ДА | ДА |
| alpha | НЕТ | ДА | НЕТ |
| sparc64 | ДА | НЕТ | НЕТ |
| ia64 | ДА | ДА | ДА |
| amd64 | ДА | ДА | ДА |
Table 2. Состояние 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
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.
| Prev | Next | |
Из-за сложности стоящих задач первоначальный план выпуска FreeBSD 5.2 и создания ветки RELENG_5 в сентябре 2003 года был сдвинут. Новый календарный план выглядит так:
18 ноября 2003: 5.2-BETA, общая заморозка кода
6 декабря 2003: 5.2-RC1, создание ветки RELENG_5_2
9 декабря 2003: 5.2-RC2
16 декабря 2003: 5.2-RELEASE
1 марта 2004: 5.3-BETA, общая заморозка кода
15 марта 2004: 5.3-RC1, создание веток RELENG_5 и RELENG_5_3
22 марта 2004: 5.3-RC2
29 марта 2004: 5.3-RELEASE
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.