IT-технологии, операционные системы, ремонт, модернизация (upgrade). 
 

2. Основные вопросы

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

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


Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
 

 2008 © osinf.ru, при публикации активная ссылка обязательна.