Алексей Федорчук - Священные войны мира FOSS

Так что же – в консольном режиме первенство остается за FreeBSD. По моему мнению – безусловно. Но – только если речь идет именно о чисто текстовой консоли. Если же обратить свой взгляд на т.н. графическую консоль (реализуемую посредством Frame Buffer) – все видится несколько иначе.

Начать с того, что графическая консоль FreeBSD (т.н. Raster Mode) ограничена одним-единственным разрешением – 800x600 (тут речь идет именно о настоящем пиксельном разрешении, а не плотности символов). Да и то – на некоторых чипах этот режим не работает вообще, на других же – имеет вид вполне скверный. Собственно, нормального результата в Raster Mode мне не удавалось добиться ни на одной из имевшихся в моем распоряжении видеокарт.

В Linux же графическая консоль просто радует взгляд. Даже при поддержке Frame Buffer для абстрактных VESA-совместимых карт на всегда ней можно варьировать разрешения от 640x480 до 1280x1024, с изменением глубины цвета в стандартном диапазоне. Что обеспечивает не только комфортный просмотр изображений, но и весьма приличное (на мой взгляд – более чем приличное) воспроизведение видео. Для карт же, имеющих хорошо реализованные собственные драйвера в ядре Linux (Matrox, ATI, чипсетное видео от Intel) – к этому добавляется возможность установки нестандартных разрешений экрана.

Конечно, никто не использует консоль для работы с изображениями, и очень немногие – для просмотра видео. Почему же я придаю графической консоли такое значение? Да потому, что незаметно, на тоненьких пока ножках, но наступает эра жидкокристаллических дисплеев, знаменующая собой смерть чисто текстового режима (но не консольного режима как такового). Почему – легко поймут те, кто видел стандартный текстовый режим 80x25 символов на 18-дюймовом LCD-мониторе с физическим разрешением матрицы 1280x1024. А как это смотрелось бы на экране с соотношением сторон 16:9 – я боюсь себе даже представить...

Наконец, остается еще один вопрос, важный для пользователя -

Представление о большем быстродействии FreeBSD по сравнению с Linux'ом – столь же традиционно, как и мнение о большей сложности ее настройки. Однако так ли все однозначно?

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

Во-вторых, даже если считать скорость загрузки одним из критериев быстродействия, – превосходство перед Linux'ом обнаруживает только FreeBSD 4-й ветки. Пятая ветка грузится ровно столько же, сколько и любой дистрибутив Linux, задействующий файловую систему устройств devfs. Конечно, в благородном Linux-семействе можно подобрать таких представителей, которые грузятся еще дольше – но это очень дружественные к юзеру системы, отягощенные... нет, не вином и едой, но изобилием стартовых сервисов (в частности, автоопределителем оборудования kudzu).

По своему сугубо пользовательскому опыту я бы сказал, что разницы в быстродействии на пользовательских задачах между Linux и FreeBSD органолептически обычно не просматривается. За двумя исключениями, первое из которых – файловые операции.

Очевидно, что на производительность файловых операций каждой ОС влияют два фактора – реализация взаимодействия с дисковой подсистемой (для десктопа – конкретно с интерфейсом ATA) и организация поддерживаемой файловой системы (систем). И вот тут-то FreeBSD оказывается в невыгодном по сравнению с Linux положении.

Выше упоминалось, что за счет CAM во FreeBSD (речь идет о 5-й ветке) достигается универсализм в работе с дисковыми контроллерами – у меня создалось впечатление, что ей вообще безразлично, на каком конкретно контроллере сидит диск (лишь бы он опознавался BIOS'ом – но и это необходимо только для загрузки с него ядра). Однако за универсализм приходится платить. И похоже, что в данном случае расплата наступает в виде снижения быстродействия дисковых операций – хотя достоверной информации по данному вопросу я не нашел, исходя из общих соображений, это выглядит похожим на правду.

Такова первая сторона вопроса. Вторая – файловая система FreeBSD, каковыми являются UFS и (по умолчанию в 5-й ветке) ее усовершенствованная модернизация UFS2. Традиционно в этой ОС обе используются в частично синхронном режиме (noasync mode), когда изменения метаданных файлов записываются на диск немедленно, а изменения блоков данных – кэшируются в оперативной памяти.

В Linux принята другая модель работы с ATA-дисками: разные типы контроллеров имеют (или не имеют) собственную поддержку в ядре. Что исключает использование явно не поддерживаемых устройств, зато для поддерживаемых, судя по всему, обеспечивает большее быстродействие. Файловые же системы (а Linux поддерживает в качестве нативных несколько их разновидностей) по умолчанию все (кроме, возможно, JFS) используются в полностью асинхронном режиме (async mode), когда и данные, и метаданные кэшируются в оперативной памяти.

В результате сочетания указанных факторов файловые операции осуществляются в Linux существенно быстрее, нежели во FreeBSD. Собственно, я всегда это подозревал, но только серия измерений показало, насколько отставание FreeBSD 5-й ветки в этом плане существенно – положение не спасает даже механизм SoftUpdates, призванный повысить и надежность, и производительность манипуляций над файлами. К слову сказать – во FreeBSD 4-й ветки такого отставания ранее не наблюдалось, что косвенно подтверждает негативное влияние работы с дисковой подсистемой (усугубляющее деградацию именно синхронных операций) – в ней модель CAM не используется (по крайней мере, не использовалась, когда я ею пользовался). А вот в Linux с его исключительно асинхронным использованием файловых систем, по моим наблюдениям, зависимости скорости работы с файлами от производительности дискового железа почти нет.

Второе из обещанных исключений относится к операциям своппинга. Каковые в Linux и FreeBSD выполняются существенно по разному. Для установления чего достаточно посмотреть на вывод команды topв той и другой ОС при среднепользовательской нагрузке. В Linux можно видеть, что при достаточном количестве оперативной памяти процент использования swap-пространства стремится к нулю. Например, на моем ноутбуке с Linux (512 Мбайт памяти) в момент сочинения этих строк, при загруженном KDE, html-редакторе Quanta, konsole, двух экземплярах konqueror и работающем mplayer (воспроизводство mpeg и RealAudio), swap не задействован вообще. На десктопе же с FreeBSD (1 Гбайт памяти) при той же нагрузке задействованная область подкачки меньше 10% почти не опускается.

Это связано с тем, что Linux прибегает к своппингу только при переполнении оперативной памяти, во FreeBSD же на диск в любом случае (даже при избытке RAM) выгружаются страницы памяти, к которым не было обращений в течении некоего промежутка времени. В сущности, оперативная память в этой ОС выступает в качестве своего рода кэша для области подкачки (точнее, для виртуальной памяти вообще). Что эффективно при ограниченном ее объеме и было оправдано в стародавние времена, когда процессоры были медленными, а памяти – мало. Ныне же такая модель использования своппинга в некоторых ситуациях приводит к замедлению работы. Пример – в KDE с большим количеством рабочих столов и периодическим переключением между ними, где такое замедление видно невооруженным глазом.