Джон К. Остерхут, Почему операционные системы ускоряются не так быстро, как это делает аппаратура

Летняя конференция USENIX.

11-15 июня, 1990.

Анахайм, Калифорния.

Джон К. Остерхут - Калифорнийский Университет в Беркли.

Источник: http://www.hpl.hp.com/.../WRL-TN-11.pdf

Почему операционные системы ускоряются не так быстро, как это делает аппаратура?

Резюме

В этой статье проводится оценка некоторых аппаратных платформ и операционных систем с помощью набора тестов, которые подвергают нагрузке вход/выход ядра, файловые системы, и другие вещи, связанные с операционными системами. Конечный результат - в том, что производительность операционной системы не повышается в той же степени, как и базовая скорость аппаратуры, на которой она установлена. Самые очевидные способы исправить ситуацию - увеличить полосу пропускания памяти и уменьшить склонность операционной системы к ожиданию завершения операций с диском.

1. Введение

Летом и осенью 1989 я собрал коллекцию тестов операционных систем. Моей целью было сравнить производительность Sprite, UNIX-совместимой исследовательской системы, разработанной в Калифорнийском Университете в Беркли [4,5], с поддерживаемыми поставщиками версиями UNIX, установленными на схожих компьютерах. После запуска тестов на некоторых конфигурациях, я заметил, что “быстрые” машины не проходят тесты так быстро, как я предполагал исходя из своих знаний о скорости их процессоров. Для того, чтобы узнать, случайность ли это, или всеобщая тенденция, я запустил тесты на большом количестве аппаратных и программных конфигураций в Западной Исследовательской Лаборатории DEC, Калифорнийский Университет Беркли и в Университете Карнеги-Меллон. Эта статья представляет результаты тестов.

Диаграмма 1 суммирует конечные результаты, которые соответствуют моим ранним наблюдениям: при повышении чистой мощности процессора скорость функций операционной системы (вызовы ядра, операции ввода-вывода, перемещение данных) не продолжает увеличиваться так же быстро. Я обнаружил, что это происходит для всех аппаратных платформ и операционных систем. Только одна “быстрая” машина, VAX 8800, смогла выполнить ряд тестов на скорости, соответствующей скорости её процессора, но 8800 - не особо быстрая машина по сегодняшним стандартам, и даже она не смогла обеспечить стабильную производительность. Другие машины работали на 10 процентов, а то и в 10 раз медленнее (в зависимости от теста), чем позволяла скорость процессора.

Тесты предлагают по крайней мере два возможных фактора, уменьшающие производительность операционной системы: полоса пропускания памяти и дисковый ввод-вывод. Архитектура RISC позволяет быстрее изменяться скорости процессора, чем полосе пропускания памяти, в результате чего интенсивные тесты памяти не используют все преимущества быстрых процессоров. Вторая проблема - в файловых системах. Файловые системы UNIX используют запись на диск перед выполнением некоторых ключевых операций. В результате производительность этих операций и файловых систем в общем тесно привязана к скорости диска и не увеличивается так быстро, как скорость процессора.

(Диаграмма 1. Суммарные рузельтаты: скорость операционной системы не увеличивается так же быстро, как и скорость аппаратуры. Геометрическое значение каждой точки - среднее значение производительности относительно MIPS для всех тестов на всех операционных системах на каждой машине. Отметка 1.0 означает, что скорость операционной системы соответствовала базовой скорости машины. Самые быстрые машины имеют значения намного меньше 1.0, что означает, что функции операционной системы работают намного медленнее исходной скорости машины.)

Тесты, которые я запускал - в основном “микро-тесты”: они оценивают конкретные особенности аппаратуры или операционной системы (такие как скорость копирования из памяти в память или вход/выход ядра). Микро-тесты довольно просто определяют отдельные плюсы и минусы систем, но они обычно не обеспечивают хорошую проверку производительности всей системы. Также я запустил один “макро-тест”, который испытал весь ряд системных функций; этот тест обеспечивает лучшее представление об общей скорости системы, но он не даёт информации о том, почему одни платформы лучше других. Я не гарантирую, что набор тестов, описанный здесь, достаточен; возможно, другой набор тестов мог принести другие результаты.

Далее статья организована следующим образом. Раздел 2 даёт сжатое описание аппаратных платформ, а Раздел 3 рассматривает операционные системы, запущенные на этих платформах. Разделы 4-11 описывают восемь тестов и результаты их запусков на разных аппаратно-программных комбинациях. Раздел 12 поводит итог и даёт некоторые рекомендации разработчикам оборудования и программ.

2. Оборудование

В таблице 1 приведены десять тестировавшихся аппаратных конфигураций. Также в таблицу включены сокращения, использующиеся в статье, показаны тип процессора (RISC или CISC) и средний уровень MIPS. Значения MIPS - мои собственные оценки; они служат для грубого представления общей производительности, обеспечиваемой каждой платформой. Основное назначение уровней MIPS - установить вероятные значения результатов тестов. Например, если производительность операционной системы сопоставима с производительностью базовой системы, тогда DS3100 должна проходить различные тесты примерно в 1.5 раза быстрее Sun4 и примерно в 7 раз быстрее Sun3.

(Таблица 1. Тестировавшиеся пппаратные платформы. “MIPS” базовую п роизводительность процессора, где значение для VAX-11/78 примерно равняется 1.0)

Все машины были обильно наделены памятью. Во время тестов не было значительного разбиения памяти на страницы. В тестах, связанных с файлами, все соответствующие файлы содержатся в кэш-буферах, предоставленных операционной системой в оперативной памяти. Различие машин - отчасти в их дисковых конфигурациях, так что небольшие отличия в тестах на ввод/вывод не должны восприниматься серьёзно. Тем не менее, все исследуюемые машины использовали одинаковые дисковые системы, исключая Mach DS3100, использовавший другие диски (немного быстрее) относительно Sprite и Ultrix DS3100.

Набор машин в Таблице 1 отражает ресурсы, доступные мне на момент запуска тестов. Он не подразумевается как полный набор всех интересующих машин, но он включает довольно широкий спектр изготовителей и архитектур.

3. Операционные Системы

Я использовал шесть операционных систем для тестов: Ultrix, SunOS, RISC/os, HP-UX, Mach, и Sprite. Ultrix и SunOS - производные от DEC и Sun, 4.3 BSD UNIX в Беркли, и схожие во многих отношениях. RISC/os - операционная система MIPS Computer Systems для машины М2000. Она является потомком System V с некоторыми дополнительными особенностями BSD. HP-UX - UNIX работы Hewlett-Packard, оня является комбинацией System V и особенностей BSD. Mach - новая UNIX-подобная операционная система, разработанная в Университете Карнеги-Меллон [1]. Она совместима с UNIX и многие особенности ядра (файловая система, в частности) перенесена из BSD UNIX. Однако, многие части ядра, включая систему виртуальной памяти и междпроцессное взаимодействие были написаны с нуля.

Sprite - экспериментальная операционная система, разработанная в Калифорнийском Университете Беркли [4,5]; несмотря на то, что её пользовательский интерфейс такой же как и в BSD UNIX, её логика ядра полностью отличается. В особенности файловая система Sprite радикально отличается от таковой в Ultrix и SunOS, а так же способы управления как сетью, так и дисками. Некоторые различия видны в результатах тестов.

Версия SunOS, используемая для тестирования Sun4 была 4.0.3, тогда как версия 3.5 была установлена на Sun3. Sun 4.0.3 включает важную реструктуризацию системы виртуальной памяти и файловой системы; например, она отображает файлы на виртуальное адресное пространство быстрее, чем хранит их в отдельном буфере кэша. Это различие отразилось в результатах некоторых тестов.

4. Вход-Выход Ядра

Первый тест измеряет затраты на вход и выход ядра операционной системы. Это производится с помощью повторяющихся вызовов функции ядра getpid и расчётом средней длительности каждого вызова. Getpid не делает ничего, кроме возврата идентификатора вызывающего процесса. Таблица 2 показывает среднее время этих запросов на различных платформах и операционных системах.

Третья колонка таблицы называется “MIPS-относительная скорость”. Она показывает, насколько хорошо машина выполнила тест относительно её уровня MIPS в Таблице 1 и времени MVAX2 в Таблице 2. Каждая запись в третьей колонке была расчитана путём деления коэффициента значения MIPS машины на значение MIPS MVAX2. Например, время getpid DS5000 было 11 микросекунд, а её значение MIPS - приблизительно 18. Таким образом, её относительная MIPS-скорость равняется (207/11)/(18/0.9) = 0.94. Значение относительной MIPS-скорости, равное 1.0, означает, что данная машина прошла тест на такой же скорости, которая предполагалась на основании времени MVAX2 и уровня MIPS из Таблицы 1. Относительная MIPS-скорость меньше 1.0 означает, что машина прошла тест намного медленнее, чем предполагалось исходя из её уровня MIPS, а значение больше 1.0 означает, что машина работала лучше, чем ожидалось.

(Таблица 2. Время вызова функции ядра getpid. “MIPS-относительная скорость” упорядочивает скорость теста по рейтингу MIPS в Таблице 1: MIPS-относительная скорость 0.5 означает, что машина прошла тест на половине от ожидаемой скорости, полученной путём сравнения рейтинга MIPS машины и MVAX2. Показания НР835 - для функции gethostid вместо getpid: getpid предлагает кешировать индекс процесса в пользовательском пространстве, таким образом избегая совершения повторных запросов к ядру (время для getpid было 4,3 миллисекунды).)

Хотя машины RISC были в общем быстрее, чем машины CISC по абсолютной шкале, они были не так быстры, как можно было бы предположить исходя из их оценок MIPS: их MIPS скорости в большинстве были в диапазоне от 0.5 до 0.8. Это говорит о том, что затраты на входа и выход ядра в машинах RISC не увеличились настолько, насколько увеличилась базовая скорость вычислений.

5. Переключение Контекста

Второй тест называется cswitch. Он измеряет затраты на переключение контекста плюс время обработки чтения и записи малых каналов. Тест работает, разветвляя дочерний процесс и затем многократно передаёт один байт между родительским и дочерним процессами, используя два канала (один для каждого направления). Таблица 3 перечисляет среднее время каждого прохода туда и обратно между процессами, которое включает один вызов функций ядра read и write в каждом процессе, плюс два переключения контекста. Как с тесто getpid, MIPS-скорости были вычислены путём сравнения значений MVAX2 и оценок MIPS в Таблице 1.

Снова машины RISC были в общем быстрее чем машины CISC, но их относительные MIPS скорости были только в диапазоне от 0.3 до 0.5. Исключения произошли только с Ultrix на DS3100, который имел относительную MIPS скорость приблизительно 0.81, и с Ultrix на DS5000, была относительная MIPS скорость которого была равна 1.02.

(Таблица 3. Затраты на переключение контекста, вычисленные как время передачи одного байта туда и обратно между двумя процессами, использующими каналы.)

6. Select

Третий тест выполняет функцию ядра call. Он создает ряд каналов, загружает данные в некоторые из них, и затем многократно вызывает select, чтобы определить, cколько из каналов читаемы. В каждой функции select используется нулевое время ожидания, чтобы функция никогда не ждала. Таблица 4 показа, как долго проходил каждый вызов функции в микросекундах, для трех конфигураций. Большая часть коммерческих операционных систем (SunOS, Ultrix, и RISC/РОТ) показали производительность в cоответствии с оценками MIPS машин, но Hewlett-Packard-UX и две исследовательских операционных системы (Sprite и Mach), были несколько медленнее чем другие.

Значения M2000 в Таблице 4 удивительно высоки для каналов, которые были пусты, но они были весьма низки, пока по крайней мере один из каналов содержал данные. Я подозреваю, что эмуляция в RISC/os's вызова функции ядра select является дефектной и заставляет процесс ждать 10 мс, даже если запрашивающая программа устанавливает мгновенное время ожидания.

7. Копирование блока

Четвертый эталонный тест использует процедуру bcopy для перемещения больших блоков данных из одной области памяти в другую. Это не испытывает операционную систему в общем, но различные операционные системы на одном и том же оборудовании отличаются, потому что их библиотеки содержат различные процедуры bcopy. Основные различия, однако, происходят из-за организации кэша и полосы пропускания памяти в различных машинах.

Результаты приведены в Таблице 5. Для каждой конфигурации я запустил эталонный тест с двумя различными размерами блока. В первом случае я использовал достаточно большие блоки (и выровненные должным образом), чтобы использовать bcopy настолько эффективно, насколько это возможно. В то же время блоки были достаточно маленькими, так что и блок-источник и блок-адресат поместились в кеш. Во втором случае я использовал размер передачи больший чем размер кэша, так, чтобы происходили неудачные обращения к кэшу. В каждом случае были сделаны несколько передач между теми же самыми источником и адресатом, и среднее значение полосы пропускания копирования показано в Таблице 5.

(Таблица 4. Время выполнения процедуры ядра select, чтобы проверить читаемость одного или более каналов. В первом столбце был использован единственный пустой канал. Во втором столбце использовались 10 пустых каналов, и в третьем столбце - десять каналов, содержащие данные. Последний столбец содержит относительные MIPS скорости, вычисленные от "10 полных" вариантов.)

(Таблица 5. Производительность процедуры bcopy при копировании большой совокупности данных. В первом столбце все данные записывались в кэш процессора (если он был), при условии "горячего старта". Во втором столбце перемещаемый блок был намного больше кэша.)

Последний столбец в Таблице 5 - относительное значение, показывющее, насколько хорошо каждая конфигурация может перемещать большие некэшированные блоки памяти относительно того, как быстро она выполняет обычные команды. Я вычислил это число, взяв значение второго ("Некэшированного") столбца и разделив его на оценку MIPS из Таблицы 1. Таким образом, для 8800 значение (16/6) = 2.7.

Интереснее всего обратить внимание на то, что машины CISC (8800, Sun3, и MVAX2) имеют упорядоченные оценки 2.7-3.7, тогда как все машины RISC, кроме RT-APC имеют оценки 1.0 или меньше. Приложения, требовательные к памяти, плохо сопоставимы с базовой скоростью машин RISC. Фактически, относительная производительность копирования памяти понижается почти монотонно с ускорением процессоров, и для RISC и CISC машин.

Относительно слабая производительность памяти машин RISC - только ещё раз говорит, что подход RISC допускает намного более быстрые центральные процессоры для данной системы памяти. Неизбежный результат этого - это то, что программы, интенсивно использующие память не будут извлекать такую выгоду от архитектуры RISC как программы, не требовательные к памяти.

7. Чтение из файлового кэша

Тест read открывает большой файл и неоднократно читает его в 16-килобайтовые блоки. Для каждой конфигурации я выбрал размер файла, который вписывался в файловый кэш оперативной памяти. Таким образом эталонный тест измерил затраты входа ядра и копирования данных из файлового кэша ядра обратно в буфер в адресном пространстве теста. Файл был достаточно большим, чтобы данные, которые копировались при каждом вызове ядра, не были расположены ни в одном аппаратном кэше. Однако, один и тот же буфер был многократно использован, чтобы получить данные от каждого вызова; в машинах с кэшем получаемый буфер, вероятно, оставался в кэше. Таблица 6 описывает полную полосу пропускания передачи данных, усредненную для большого количества вызовов ядра.

(Таблица 6. Производительность вызова read ядра при чтении большого количества блоков данных из файла, достаточно маленьких, чтобы вписаться в файловый кэш оперативной памяти.)

Значения в Таблице 6 достаточно близки полосе пропускания памяти в Таблице 5. Единственные значимые различия - для Sun4 и DS5000. Sun4 относительно лучше проходит этот тест из-за его кэша обратной записи. Так как получаемый буфер всегда остается в кэше, его содержание перезаписывалось без сохранения в памяти. У всех других машин был кэш сквозной записи, который немедленно сбрасывал информацию в буфере в память. Второе отличие от Таблицы 5 - DS5000, который был намного медленнее чем ожидалось; у меня нет объяснения этому несоответствию.

8. Модифицированный тест Эндрю

Единственный крупномасштабный эталонный тест в моем испытательном наборе программ - измененная версия эталонного теста Эндрю, разработанного М. Сэтьянэрайянэном для измерения производительности файловой системы Эндрю [3]. Эталонный тест работает, копируя иерархию директории, содержащую исходный текст для программы, открывая каждый файл в новой иерархии, читая содержание каждого скопированного файла, и, наконец, компилируя код в скопированной иерархии.

Оригинальный эталонный тест Сэтьянэрайянэна использовал компилятор C, установленный на машине-хосте, что делало невозможным сравнение продолжительности запуска между машинами с различной архитектурой или различными компиляторами. Чтобы сделать результаты сопоставимыми между различными машинами, я изменил эталонный тест так, чтобы он всегда использовал один и тот же компилятор, которым является GNU C компилятор, генерирующий код для экспериментальной машины под названием SPUR [2].

Таблица 7 содержит сырые результаты Эндрю. Таблица приводит отдельные длительности для двух различных фаз теста. Фаза "копии" состоит из всего кроме компиляции (все копирования файла и сканирования), фаза "компиляция" содержит только компиляцию. Фаза копии намного интенсивнее изпользует ввод/вывод чем фаза компиляции, это также осложняет использование механизмов для создания процесса (например, чтобы скопировать каждый файл, используется отдельная команда оболочки). Фаза компиляции ограничена скоростью процессора на медленных машинах, но она занимает существенное время при вводе - выводе на более быстрых машинах.

Я выполнил эталонный тест и на локальных и на отдаленных конфигурациях. "Локальный" означает, что все файлы, к которым обращается эталонный тест, хранились на диске, прикрепленном к машине, выполняющей эталонный тест. "Бездисковые" обращения к конфигурациям Sprite были на машине, выполняющей эталонный тест, у которой не было никакого локального диска; все файлы, включая бинарные программы, были скопированы и скомпилированы, а временные файлы обращались по сети, используя протокол [4] файловой системы Sprite. "NFS" означает, что для обращения к удалённым файлам использовался протокол NFS. Для измерений NFS SunOS машина, выполняющая эталонный тест, была без диска. Для измерений Ultrix и Mach у машины, выполняющей эталонный тест, был локальный диск, который использовался для временных файлов, но ко всем другим файлам были удалённые обращения. "AFS" означает, что для обращения к удалённым файлам использовался протокол файловой системы Эндрю [3]; эта конфигурация была похожа на NFS под Ultrix тем, что у машины, выполняющей эталонный тест, был локальный диск, и временные файлы хранились на нём, в то время как к другим файлам обращались дистанционно. Во всех случаях сервер был той же конфигурации, что и клиент.

Таблица 8 дает дополнительные "относительные" значения: относительное MIPS быстродействие для локальных испытаний, относительное MIPS быстродействие для отдаленных испытаний, и процент замедления, когда эталонный тест работал с отдаленным диском вместо локального.

В Таблицах 7 и 8 есть несколько интересных результатов. Прежде всего, у более быстрых машин в общем есть меньшие относительные MIPS скорости чем у более медленных машин. Это проще увидеть, сравнивая различные машины с одинаковыми операционными системами, такие как Sprite на Sun3, Sun4 и DS3100 (1.7, 0.93, и 0.89 соответственно для локального случая), или SunOS на Sun3, Sun4, и SS1 (1.4, 0.85, 0.66 соответственно для локального случая), или Ultrix на MVAX2, 8800, и DS3100 (1.0, 0.93, и 0.50 соответственно для локального случая).

Второй общий результат из Таблиц 7 и 8 - то, что Sprite оказался быстрее чем другие операционные системы во всех случаях, кроме сравнения с Mach на Sun4. Для локального случая Sprite был на 10-20% быстрее, но в удаленном случае Sprite был, как правило, на 30-70% быстрее. На Sun-4 и DS3100 для удалённых случаев Sprite был на 60-70% быстрее чем Ultrix, SunOS, либо Mach. Фактически, комбинация Sprite-DS3100 выполнила эталонный тест дистанционно на 45% быстрее чем Ultrix-DS5000, даже при том, что у комбинации Ultrix-DS5000 было приблизительно на 50% больше мощности центрального процессора. Таблица 8 показывает, что Sprite выполнил эталонный тест почти столь же быстро дистанционно как в местном масштабе, тогда как другие системы, замедлились на 20-60%, работая дистанционно с NFS или AFS. Кажется, что штраф за использование NFS увеличивается вместе с увеличением машинных скоростей: у MVAX2 был удаленный штраф 21%,у Sun3 - 34% и у Sun4 - 63%.

(Таблица 7. Время, затраченное на выполнение измененной версии эталонного теста М. Сэтьянэрайянэна Эндрю [3]. Первый столбец показывает полное время для всех фаз эталонного теста кроме фазы компиляции. Второй столбец показывает время, затраченное на компиляцию, и третий столбец выводит полное время теста. Записи таблицы упорядочены по полному временеми выполнения.)

(Таблица 8. Относительная производительность эталонного теста Эндрю. Первые два столбца описывают относительное локальное и отдаленное MIPS быстродействие. Первый столбец вычислен относительно локального времени MVAX2 Ultrix 3.0, второй столбец вычислен относительно MVAX2 Ultrix 3.0 NFS. Третий столбец показывает удаленный штраф - дополнительное время, требуемое для выполнения эталонного теста дистанционно, как процент от времени выполнения в местном масштабе. Записи в таблице упорядочены по удаленному штрафому.)

Третий интересный результат этого эталонного теста состоит в том, что комбинация DS3100-Ultrix-Local медленнее, чем я ожидал: это приблизительно на 24 % медленнее чем DS3100-Mach-Local и на 78 % медленнее чем DS3100-Sprite-Local. Комбинация DS3100-Ultrix не получила столь же большой удаленный штраф как другие конфигурации, но это потому, что её местное время оказалось необычно медленным.

(Таблица 9. Затраченное время на открытие и закрытие файла, используя вызовы ядра open и close. Относительные MIPS скорости для случая "foo" относительно MVAX2 Ultrix 3.0. Локальны для локальных конфигураций и относительны MVAX2 Ultrix 3.0 NFS для отдаленных конфигураций.)

10. Open-Close

Модифицированный тест Эндрю предполагает, что файловая система Sprite быстрее чем другие файловые системы, особенно для удаленного доступа, но это не определяет, какие особенности файловой системы надёжны. Я выполнил два других эталонных теста в попытке точно определить различия. Первый эталонный тест - open-close, который неоднократно открывает и закрывает отдельный файл. Таблица 9 отображает затраты на вызов open-close для двух случаев: название, состоящее только из одного элемента и из 4 элементов. И в локальных и в отдаленных испытаниях производные UNIX были быстрее чем Sprite. Длительности удалённой обработки преимущественно состоят из времени доступа к серверу: Sprite соединяется с сервером при каждом open и close, NFS иногда соединяется с сервером (чтобы проверить состав его кэшируемой информации), а AFS фактически никогда не сверяется с сервером (сервер должен уведомить клиента, когда кэширование информации становится недопустимым). Из-за его способности избегать всех взаимодействий с сервером на повторном доступе к одному и тому же файлу, AFS был, безусловно, самой быстрой удаленной файловой системой в этом эталонном тесте.

Хотя этот тест показывает разительные отличия в затратах на open-close, это, кажется, не объясняет различия производительности в Таблице 8. Относительные MIPS скорости более различны для операционных систем, чем для машин. Например, все относительные MIPS скорости Mach и Ultrix были в диапазоне от 0.8 до 1.1 для локального случая, тогда как все скорости Sprite были в диапазоне от 0.27 до 0.34 для локального случая.

11. Create-Delete

Последний эталонный тест был, возможно, самым интересным с точки зрения идентификации различий между операционными системами. Это также помогает объяснить результаты в Таблицах 7 и 8. Этот эталонный тест моделирует создание, использование и удаление временного файла. Он открывает файл, записывает в него некоторые данные и закрывает его. Потом он открывает файл для чтения, читает данные, закрывает файл, и, наконец, удаляет. Я попробовал три различные по объёму совокупности данных: 0, 10 и 100 кб. Таблица 10 показывает полное время создания, использования и удаления файла для каждой из конфигураций аппаратно-программных средств.

Этот эталонный тест показывает основное различие между Sprite и производными UNIX. В Sprite недолговременные файлы могут быть созданы, использованы и удалены даже будучи без данных, когда-либо записанных на диск. Информация сохраняется на диск только после того, как файл прожил по крайней мере 30 секунд. Sprite использует только один дисковый ввод-вывод для каждой итерации эталонного теста, чтобы выписать i-узел файла после того, как он был удалён. Таким образом в лучшем случае (DS3100) каждая итерация занимает одно дисковое вращение, или приблизительно 16 мс. Даже этот ввод-вывод - исторический экспонат, который больше не используется; более новая версия файловой системы Sprite избавляется от этого, завершая тест всего лишь за 4 мс для локального случая DS3100 без данных.

(Таблица 10. Затраченное время на создание файла, запись в него некоторого количества байт, закрытие, затем вновь открытие файла, чтение, закрытие и удаление. Этот эталонный тест моделирует использование временного файла. Комбинация Mach-AFS показала большую изменчивость: такие высокие длительности как 460мс/721мс/2400мс были так же распространены, как и времена, отмеченные выше (времена в таблице - самые низкие среди отмеченных). Относительные MIPS мкорости были вычислены, используя время "Без Данных" по сравнению с локальным MVAX2 или временем NFS. Таблица отсортирована в порядке значений "Без Данных".)

UNIX и все его производные намного больше ограничены в использовании дисков, чем Sprite. Когда файлы создаются и удаляются, несколько блоков информации должны быть отправлены на диск, и операции не могут завершиться, пока не завершится ввод-вывод. Даже для файлов без данных все производные UNIX потратили 35-100мс на создание и удаление файла. Это наводит на мысль, что такая информация как i-узел файла, записи в каталоге, или i-узел каталога записывается на диск. В основанных на NFS отдаленных системах недавно созданные данные должны быть переданы по сети на файловый сервер и затем на диск прежде, чем файл сможет быть закрыт. Кроме того, NFS вызывает каждый блок с диска независимо, сохраняя i-узел файла и любые косвенные блоки один раз для каждого блока в файле. Это приводит к 3 дисковым вводам-выводам для каждого блока. В AFS измененные данные возвращаются на файловый сервер как часть операции закрытия. Результат всех этих действий состоит в том, что производительность теста create-delete под UNIX (и производительность временных файлов под UNIX) определены скорее быстродействием диска, чем быстродействием центрального процессора.

Тест create-delete позволяет объяснить слабую производительность DS3100 Ultrix на эталонном тесте Эндрю. Основное время создания пустого локального файла на 60% больше в DS3100-Ultrix чем в 8800-Ultrix, даже при том, что центральный процессор DS3100 вдвое быстрее процессора 8800. Время для 100-килобайтового файла в DS3100-Ultrix-NFS в 45 раз больше чем для DS3100-Sprite без диска! Слабая производительность относительно 8800 может быть обусловлена, в частности, медленными дискамм (RZ55 на DS3100). Однако, слабая удаленная производительность Ultrix только частично зависит от политики смещения-при-закрытии NFS: скорость записи DS3100-Ultrix-NFS достигает только приблизительно 30 кб/сек на 100-килобайтовых файлах, что является почти в два раза медленнее, чем я увидел на подобной аппаратуре с более ранней версией Ultrix 3.0, и в три раза медленнее чем на Mach. Я подозреваю, что Ultrix мог быть настроен для обеспечения существенно лучшей производительности файловой системы.

12. Выводы

В почти каждом эталонном тесте более быстрые машины работали медленнее, чем я предположил исходя из чистого быстродействия процессора. Хотя, опасно делать далеко идущие выводы на основании маленького набора эталонных тестов, я думаю, что тесты указывают на четыре области потенциальных проблем, две - для проектировщиков оборудования и две - для разработчиков операционных систем.

12.1 Аппаратные Проблемы

Первая проблема, связанная с аппаратными средствами - полоса пропускания памяти: эталонные тесты показывают, что она не соответствует быстродействию центрального процессора. Отчасти это происходит из-за 3-4-кратного различия в быстродействии центрального процессора и полосы пропускания памяти в более новой архитектуре RISC относительно старой CISC; это - единовременный эффект, который происходит в переходе с RISC на CISC. Однако, я полагаю, в ближайшие годы системным проектировщикам будет сложнее увеличивать производительность памяти с такой скоростью, как они улучшают производительность процессора. В частности, серьезные ограничения накладываются рабочими станциями, которые могут подтолкнуть проектировщиков к ограничению производительности системы памяти. Если полоса пропускания памяти резко не улучшится в будущих машинах, некоторые классы приложений могут быть ограничены производительностью памяти.

Вторая проблема аппаратных средств - переключение контекста. Тесты getpid и cswitch показывают, что переключение контекста и для вызовов ядра и для переключений процесса происходит в 2 раза медленнее в машинах RISC, чем в CISC. У меня нет объяснения такому результату, так как наличие дополнительных регистров в машинах RISC - не является достаточным объяснениям такого различия. Ухудшение в 2 раза, возможно, не будет слишком значимо, пока относительная производительность переключения контекста не начнёт ухудшаться в будущих машинах.

12.2 Программные Проблемы

По моему мнению, одна из самых больших проблем для разработчиков операционных систем состоит в том, чтобы сделать независимой производительность файловой системы от дисковой производительности. Операционные системы - потомки UNIX используют кэш, чтобы ускорить чтение, но они требуют синхронного дискового ввода-вывода для операций, изменяющих файлы. Если эта связь не будет устранена, то большое количество программ, интенсивно использующих файлы, получит мало преимуществ от ускорения аппаратных средств, или вообще не получит таковых. Конечно, отсрочка записи на диск может привести к информационной потере во время сбоев; проблема для проектировщиков операционных систем состоит в том, чтобы поддержать приемлемый уровень надежности, сделав независимой производительность.

В качестве популярного подхода, может использоваться энергонезависимая память как буфер между оперативной памятью и диском. Информация может быть немедленно записана (и эффективно) в энергонезависимую память так, чтобы это она смогла пережить сбои; долговременная информация может в конечном счете быть записана на диск. Этот подход дополнительно осложнён задачей переместить информацию сначала в энергонезависимую память, и затем - на диск, но это может немедленно привести к улучшению полной производительности сравнительно с непосредственной записи на диск. В качестве другого подхода могут быть использованы файловые системы с журнальной структурой, которые делают независимой производительность файловой системы от дисковой производительности и производят дисковый ввод-вывод более эффективно. См. [6] для подробностей.

В заключении обращаю ваше внимание на области сетевых протоколов. По моему мнению, принципы, присущие NFS (отсутствие структуры и сквозная запись при закрытии, в особенности), представляют фундаментальное ограничение производительности. Чтобы пользователи получили преимущества более быстрых машин, любая NFS должна быть пересмотрена (мой выбор), или NFS должна стать менее интенсивной для диска.

13. Доступ к коду

Исходный текст всех этих эталонных тестов доступен через общественный FTP на ucbvax.berkeley.edu. Файл pub/mab.tar.Z содержит измененный эталонный тест Эндрю, а pub/bench.tar.Z содержит все другие эталонные тесты.

14. Благодарности

M. Сэтьянэрайянэн разработал оригинальный эталонный тест Эндрю и предоставил мне доступ к IBM RTAPC на Mach. Джей Кистлер разрешил несовместимость, которая первоначально препятствовала тому, чтобы измененный эталонный тест Эндрю работал под Mach. Джефф Могул и Пол Викси помогли мне получить доступ к машинам в DEC и их ядрам для тестирования, и объяснили запутанную конфигурирацию NFS. Рик Рэшид предоставил мне результаты эталонного теста для Mach, на DS3100 и Sun4. Джоуль Маккормакк и Дэвид Вол обеспечили полезными комментариями к более ранним проектам этой статьи.