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

2.1. SMPng

Работам над 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 используется в большинстве кода ядра и подпрограммах обработки прерываний драйверов устройств, вызывает множество лишних переключений контекста и может сказаться на производительности. Ведётся работа по выяснению того, как сделать вытесняемость условной.

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

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

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

• Как вариант — задействовать особый вид легковесных ithread. Это могло бы привести к уменьшению количества сохраняемых контекстов для ithread, к заимствованию стека из другого kthread и/или к созданию нового быстрого пути, исключающего вызов mi_switch().

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

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

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

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

  Таблица 1. Состояние KSE

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

  Таблица 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

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

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

• KSE: и компоненты уровня ядра, и компоненты пользовательского уровня должны достичь одинакового уровня функциональности во всех платформах уровня Tier-1 в UP и SMP конфигурациях. Определение того, что является ''платформами ранга Tier-1'', можно найти в http://www.FreeBSD.org/doc/ru_RU.KOI8-R/articles/committers-guide/archs.html. При приближении к выпуску ветки 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.

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

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

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

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

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

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

Для выявления проблем с производительностью и борьбы с её ухудшением необходимо информативное и надёжное проведение тестов. Вскоре должна быть сформирована ''группа производительности'' из людей и ресурсов для формулирования, разработки и выполнения стандартных тестов производительности. Сравнения должны делаться как с 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.

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

• 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).

• Новый планировщик задач: он уже готов, и пользователи могут выбирать между классическим планировщиком 4BSD и новым планировщиком ULE. В ветке RELENG_5 должен быть планировщик, имеющий привязку к процессору, поддержку HyperThreading и KSE, а также отсутствие снижения производительности или времени реакции системы.

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

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

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

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