рамі ядра. Потім ми значний змінілі код, Відаль з ядра драйвером прістроїв и Дода засоби Підвищення надійності, что обговорюваліся в розд. 3. Таким чином, ми отримай практично нову систему MINIX 3 без вимагатиме у напісанні великого ОБСЯГИ кодом, що не істотного для даного проекту, такого як драйверами І файлової системи.
Оскількі нас Цікавить ВАРТІСТЬ змін, что обговорюваліся в даній статьи, мі порівнюємо свою систему з базовою системою, в якій драйвером прістроїв є Частинами ядра, Шляхом запуску одних І тіх же тестів на обох системах. Це набагато більш чистий перевірка, чем порівняння Нашої системи з Linux або Windows, Яку нагадував б порівняння яблук з ананасами. Таким порівнянь часто заважають Відмінності в якості компіляторів, в стратегіях Розгорнути управління пам'яттю, у файлових системах, в обсязі віконаної оптімізації, в зрілості систем и в багатьох других факторах, Які могут Повністю затініті всі Інше.
тестовому системою БУВ 2.2 GHz Athlon (більш точно, AMD64 3200) з 1 Гб ОСНОВНОЇ пам'яті І 40 гігабайтнім диском IDE. Жоден з драйверів НЕ БУВ оптімізованій для роботи в режімі користувача. Наприклад, ми очікуємо, что на Pentium зможемо Забезпечити захіщенім чином прямий доступ драйверів прістроїв до необхідніх їм портів ВСТУП-Виведення, усуваючі, таким чином, багатая вікліків ядра. Однак для ПІДТРИМКИ переносімості інтерфейс не якщо змінюватіся. Крім того, в Данії годину в драйвери вікорістовується програмованій ВСТУП-Виведення, что набагато повільніше Використання DMA. После реалізації ціх оптімізацій ми очікуємо істотного Підвищення ефектівності. Тім не менше, даже при вікорістанні існуючої системи погіршення продуктівності виявило Цілком Розумний.
Результати тестування системних вікліків
Перший пакет тестів містів тести чистих POSIX-сумісніх системних вікліків. Корістувацька программа винна булу зафіксуваті реальний годину у тактах системних годин (на частоті 60 Гц), потім Мільйони разів сделать системний виклик, после чого вновь зафіксуваті реальний годину. Година ОБРОБКИ системного виклику обчіслювалося як різніця между кінцевім І початкова годиною, поділена на кількість вікліків, за Вирахування накладних витрат на організацію циклу, Які вімірюваліся окремо. Число ітерацій циклу Було різнім для шкірного тесту, оскількі тестування 100 миллионов разів виклику getpid Було Розумного, альо читання 100 миллионов разів з 64-магабайтного файлу зайнять бі Надто багатая годині. Всі тести віконуваліся на незавантаженіх Системі. Для ціх тестів частоти успішніх звернень до кешу ЦП и кешу файлового сервера імовірно становили 100%.
Коротко проаналізуємо результати ціх тестів. Виконання системного виклику getpid зайнять 0.831 мсек при вікорістанні ядерних драйверів и 1.011 мсек при вікорістанні драйверів, что Працюють в режімі користувача. При віконанні цього виклику від корістувацького процеса менеджерові пам'яті надсілається одиночному ПОВІДОМЛЕННЯ, на Яку негайно виходе відповідь. При вікорістанні драйверів, Які віконуються в режімі користувача, виклик віконується повільніше з-за наявності перевіркі прав процесів на посилка таких Повідомлень. При віконанні такого простого виклику істотне уповільнення віклікають даже кілька Додатковий рядків коду. Хочай у відсотках різніця становіть 22%, на кожен виклик вітрачається позбав 180 Додатковий наносекунд, так что даже при частоті 10,000 звернень в секунду ВТРАТИ складають Всього 2.2 мсек в секунду, набагато менше 1%. При віконанні виклику lseek проводитися набагато велика робота, І того відносні накладні витрати зніжуються до 11%. При віконанні Відкриття та Закриття файлу цею Показник становіть позбав 9%.
Читання и запис 64-кілобайтній ділянок даніх займає менше 90 мсек, и Падіння продуктівності складає 8%. При вікорістанні драйверів, что віконуються в режімі користувача, создания файлів, записів в нього +1 кілобайт даніх І видалений даніх займають 13.465 мсек. Через Використання буферного кешу файлового сервера в Жодний з ціх тестів НЕ віклікаліся драйверами, и того Ми можемо укласті, что Другие Зміни, які не пов'язані з драйверами, сповільнюють систему пріблізно на 12%.
Результати тестування дискового ВСТУП-Виведення
У іншому пакеті тестів ми читали з файлу І писав у файл порції від 1 кілобайт до 64 мегабайт. Тести пропускаєш багатая разів, так что чітається файл розміщувався у 12-мегабайтную кеші файлового сервера, крім випадка 64-мегабайтную обмінів, колі ОБСЯГИ кешу НЕ вістачало. Використання внутрішнього кеша дискового контролери не блокувалося.
Як ми Бачимо, різніця в продуктівності становіть від 3% до 18%, у Середнє - 8.4%. Однак зауважімо, что найгіршій Показник продуктівності ОТРИМАНО для 1-кілобайтній запісів, альо абсолютна годиною зросла Всього на 457 наносекунд. Це співвідношення зменшується при збільшенні ОБСЯГИ ВСТУП-Виведення, оскількі скорочуються відносні накладні витрати. У трьох 64-магабайтніх тестах, результати якіх пока...
