Я провёл большую часть хакофона удаляя файлы, связанные с различными====
слоями бинарной совместимости. Основная мотивация в их удалении - это
уменьшить число файлов которые надо инспектировать и редактировать при
больших модификациях которые мы планируем при улучшении поддержки нитей
(тредов). Несмотря на привлекательность концепции запуска программ
скомпилированных для других операционных систем, это помогло на ранних
этапах развития OpenBSD, востребованность кода совместимости неясна, было
проявлено мало внимания к его тестированию и поддержке. Не весь compat
код будет удалён на этот раз, но содействие в продолжении использования
проприетарных программ идёт в разрез с целями проекта.
Включение mandoc(1) также вскрыло факт построения многочисленной и
избыточной документации groff'ом. Многое из этого было устаревшим и тоже
может быть удалено. Мы также не уверены что нам делать с оставшейся
документацией в долговременной перспективе, но сужение круга кандидатов
может помочь в дальнейшем.
С точки зрения нового кода, я исследую новые пути установления
прикладного адресного пространства, в частности на i386. Различные
сегменты адресного пространства отмеряются и располагаются согласно
макросам в $arch/include/vmparam.h. Наша существующая политика
резервирует пространство для каждого сегмента, даже если он не
используется. Одна из областей - это традиционная область кучи
используемая системным вызовом brk. Из man brk(2): "Функции brk(2) и
sbrk(2) - это исторические курьезы оставленные в былые дни до появления
виртуальной памяти." OpenBSD редко использует вызов brk(2), вместо него
используется исключительно mmap(2) (или malloc для большинства программ),
но место для [кучи] всё равно оставляется. Это является неприятным
эффектом для mmap(2), которому сокращают доступные адреса. Мы можем
уменьшить резервируемый размер, но существуют "исторические курьезы"
которые до сих пор его используют. Задача такая: с наименьшим
беспокойством кода uvm (прим. система управления виртуальной памятью
пришедшая из NetBSD), мы можем позволить существовать вместе и brk(2) и
mmap(2) и позволить им эффективно перекрываться (прим. видимо их областям
памяти). Конечно, i386 сама по себе является историческим курьёзом, но я
подозреваю что люди до сих пор её используют, и надеюсь выжать максимум
из ограниченности адресного пространства, на долгие годы.
Я также провёл целый день над новым методом ускорения центрального
процессора. Мы долгие годы раскрывали [пользователю] sysctl переменную
hw.setperf которая представляет собой возможность управления частотой
процессора (и как следствие мощностью и тепловыделением). У нас также
имеется опция в apmd которая наблюдает за системной загрузкой и
подстраивает скорость в соответствие [с загрузкой]. Существуют две
хорошо известные проблемы такого решения. Первая, алгоритм не учитывает
количество ядер. Вторая, интервал опроса немного медленный (прим.
возможно имеется занимает длительное время сам опрос). В то время как он
[алгоритм] хорошо работает для долгоиграющих задач, таких как компиляция,
интерактивные задачи, такие как перемотка в браузере, выглядят
медленными. Ваш процессор не выкручивается на высокую скорость до тех
пор пока операция не будет закончена. Частота опроса из прикладного
пространства сама представляет собой проблему, так как создаёт
дополнительную нагрузку (эффект наблюдателя!).
Для решения проблемы я перенёс код подстройки [частоты] в ядро, для того
чтобы можно было вызывать его часто без потерь на многочисленные
переключения контекстов прикладное пространство/ядро. Мы также
подстроили отзывчивость алгоритма к каждому процессору. В то время как
нынешний патч использует информацию от apmd, другим достоинством переноса
кода в ядро является возможность более тесной интеграции с планировщиком
в будущем. Например, можно пофантазировать про то как планировщик будет
мгновенно переключать процессор в медленный режим когда он выполняет
холостой цикл.
Тэд Юнангст
Ну, что я могу сказать, не правда ли здорово что tedu@ предпочитает серфингу на Гудзоне хакерство по выходным. Долгие годы он оставался моим любимым [подписчиком] в misc@ и я был счастлив встретить его в живую. Он сделал большую работу и является для меня и многих других вдохновением. Спасибо тебе за твою огромную и продолжающуюся работу над OpenBSD. Я надеюсь что другие также смогут воодушевиться для создания и отправки патчей и/или хотя бы сделать пожертвование в качестве небольшого вклада для поддержки предстоящих (мини-)хакофонов. Мы ценим твою поддержку и внимание.
> Марк Т. Уемура