7. Вимірювання продуктивності
Продуктивність є проблемою, супутньої мінімальним ядер протягом десятиліть. Тому негайно постає питання: у що обходяться що обговорювалися вище зміни? Щоб розібратися в цьому, ми створили прототип, що складається з невеликого ядра і підтримуваного їм набору драйверів пристроїв і серверів, що працюють в режимі користувача. В якості основи прототипу ми почали з використання системи MINIX 2 з-за її невеликого розміру і довгої історії. Код системи вивчався багатьма десятками тисяч студентів в сотнях університетів протягом 18 років, і в останні 10 років майже не надходили повідомлення про помилки, що мають відношення до ядра; мабуть, відсутність помилок пов'язано з малими розмірами ядра. Потім ми значно змінили код, видаливши з ядра драйвери пристроїв і додавши засоби підвищення надійності, що обговорювалися в розд. 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-магабайтних тестах, результати яких показані на рис. 6 і 7, це співвідношення становить всього від 3% до 5%.
В іншому тесті проводиться читання з безпосереднього блокового пристрою, відповідного жорсткого диска. Запис на безпосереднє пристрій зруйнувала б його вміст, тому такий тест не виконувався. При виконанні цих тестів не використовується буферний кеш файлової системи, і перевіряється тільки переміщення бітів з диска. Як ми бачимо, в цьому випадку середній показник накладних витрат становить лише 9%.
Результати тестування додатків
Наступний набір тестів складався з реальних програм, а не простих вимірів часу виконання системних викликів. Результати наведено на рис. 8. Перший тест полягав у побудові області початкового завантаження (boot image) у циклі, що містить виклик system («make image»); тим самим, побудова вироблялося багато разів. При кожному побудові компілятор мови C викликався 123 рази, асемблер – 4 рази і компонувальник – 11 разів. Побудова ядра, драйверів, серверів і програми init, а також збірка області початкового завантаження зайняли 3.878 секунд. Середній час компіляції становило 32 мсек на файл.
Другий тест містив цикл, у якому компілювати тести відповідності стандарту POSIX. Набір з 42 тестових програм компілюватися за 1,577 секунди, або приблизно за 37 мсек на файл тесту. Тести з третього по сьомий складалися в сортуванні до 64-мегабайтной файлу та застосування до нього sed, grep, prep і uuencode відповідно. У цих тестах у різних обсягах змішувалися обчислення і обміни з диском. Кожен тест пропускався лише по одному разу, так що кеш файлової системи практично не використовувався, кожен блок брався з диска. Середнє падіння продуктивності склало в цих випадках 6%. Якщо взяти середнє значення для останнього стовпця показників 1922 тестів, відображених на рис. 6–8, ми отримаємо 1.08. Іншими словами, версія з драйверами, що виконуються в режимі користувача, виявилася приблизно на 8% повільніше версії з ядерними драйверами для операцій, які залучають обміни з дисками.
Мережева продуктивність
Ми тестували також і мережеву продуктивність системи з драйверами, що виконуються в режимі користувача. Тестування проводилося з використанням карти Intel Pro/100, оскільки у нас не було драйвера для карти Intel Pro/1000. Ми змогли управляти Ethernet на повній швидкості. Крім того, ми запускали тести поворотної петлі з відправником та одержувачем, що знаходяться на одній машині, і спостерігали пропускну здатність в 1.7 Гб / сек. Оскільки це еквівалентно використанню мережевого з'єднання для посилки на швидкості 1.7 Гб / сек і одночасного прийому на тій же швидкості, ми впевнені, що управління гігабітної апаратурою Ethernet з єдиним односпрямованим потоком на швидкості в 1 Гб / с не повинна створити проблему при використанні драйвера, що виконується в режимі користувача.
Розмір коду
Швидкість – це не єдиний показник, який представляє інтерес; дуже важливим є і кількість помилок. На жаль, ми не можемо безпосередньо перерахувати всі помилки, але розумним замінником числа помилок, ймовірно, є число рядків коду. Нагадаємо: чим більше код, тим більше помилок.
Підрахувати кількість рядків коду не так просто, як може здатися на перший погляд. По-перше, порожні рядки і коментарі не додають в код складності, і тому ми їх не враховуємо. По-друге, # define й інші визначення у файлах заголовків також не додають у код складності, і тому файли заголовків теж не враховуються. Підрахунок числа рядків виконувався з використанням Perl-скрипта sclc.pl, доступного в Internet. Результати для ядра, чотирьох серверів (файлової системи, сервери процесів, сервера реінкарнації, інформаційного сервера), п'яти драйверів (жорсткого диска, флоппі-диска, RAM-диска, терміналу, пристрої журналізацію) і програми init показані на рис. 9.
На малюнку можна бачити, що ядро складається з 2947 рядків на мові C і 778 рядків на мові асемблера (для програмування низькорівневих функціональних можливостей, таких як перехоплення переривань і збереження регістрів ЦП при перемиканні процесів). Всього є 3725 рядків коду. І тільки цей код виконується в режимі ядра. Іншим способом вимірювання розміру коду для C-програм є підрахунок числа точок з комою, оскільки багато операторів мови C завершуються крапкою з комою. У коді ядра є 1729 точок з комою. Нарешті, розмір скомпільованій ядра складає 21,312 байт. Це число задає тільки розмір коду (тобто сегмента тексту). Початкові дані (3800 байт) і стек в це число не входять.
Цікаво, що статистика розмірів коду, показана на рис. 9, представляє мінімальну, але функціонуючу операційну систему. Загальний розмір ядерної частини і частини, що працює в режимі користувача, складає всього 18,000 рядків коду, незвичайно мало для POSIX-сумісної операційної системи.
0 комментариев