 |
|
|
|
Практика работы с NetBSD: профилирование ядра
Практика работы с NetBSD: профилирование ядра Перед началом рассмотрения процесса профилирования я предполагаю, что вы установили исходные тексты системы и умеете перекомпилировать ядро. Как это сделать, было описано в статье «Первые шаги в NetBSD. Часть 1», опубликованной в июньском номере журнала. Целью и задачей профилирования ядра служит сравнение производительности старого и нового ядра. Например, вы скомпилировали новое ядро, и по вашим расчетам оно должно работать быстрее первого, но желаемого результата получено не было. В чем дело? Где вы ошиблись? Все это можно будет выяснить, используя профилирование ядра. Если вы собираете NetBSD для какой-либо встроенной системы, без профилирования вам точно не обойтись. Ведь во встроенных системах аппаратные характеристики железа, как правило, очень ограниченны. А без использования профилирования вряд ли удастся настроить систему на оптимальную производительность. Рассмотрим пример профилирования для NetBSD, работающей на обычном x86-компьютере. Для примера мы возьмем ядро GENERIC, поставляющееся с системой по умолчанию, и сравним его по производительности с собранным вами новым ядром. Соберем профилированное GENERIC-ядро. Переходим в каталог, где располагаются конфигурационные файлы ядра: # cd /sys/arch/i386/conf/ Опция –p указывает, что собираемое ядро будет профилироваться: # config –p GENERIC Запускаем сборку ядра: # cd ../compile/GENERIC.PROF/ # make depend && make Сохраняем старое ядро: # cp /netbsd /netbsd.old Копируем в корень новое: # cp netbsd /netbsd Перезагружаемся: # reboot Сразу после загрузки системы проверим, работает профилирование или нет. # kgmon – b В ответ мы должны получить:
Теперь отключим профилирование: # kgmon –h В ответ мы получим:
Теперь нам нужно поместить данные kgmon в файл. # kgmon –p После этой команды мы получим файл gmon.out размером около 3 Мб. Далее нам нужно получить вывод gprof: #gprof /netbsd > gprof.out Должен заметить, имя файла для вывода можно выбрать самому. Примерно через 2-3 минуты в текущем каталоге появится заказанный нами файл gprof.out. После этого переходим непосредственно к процессу анализа полученных данных. Смотрим наш gprof.out (или как вы его назвали). Первым разделом идет Flat profile, это список всех вызванных функций, время и количество их вызовов. Вот пример части вывода:
Дальше в том же духе. Давайте рассмотрим содержание этих столбцов более подробно.
Как видно из этого фрагмента, подавляющее большинство времени система бездействовала. Теперь следует раздел Call Graph Profile. Его задача – показать дальнейшие запросы («потомки») от перечисленных функций. Вот часть вывода:
И так далее. Всего 6 столбцов с данными.
Следующим разделом этого файла является список всех функций, которые указывались выше, отсортированные в алфавитном порядке, и с указанием уникального номера, присвоенного в разделе Call graph profile. После того как мы проанализировали полученные данные, давайте создадим еще одно ядро системы. Отличие от «оригинального» будет в заведомой «заторможенности» одной из функций. Для примера (как и в NetBSD handbook) возьмем функцию check_exec. Настало время немного поправить ядро системы. Берем свой любимый текстовый редактор и открываем файл /usr/src/sys/kern/kern_exec.c. Ищем там функцию check_exec и добавляем в конце вот такой код: for (x = 0; x < 100000000; x++) { y = x; } Не забыв в начале функции check_exec, написать: int x; int y; После внесения этих нехитрых изменений, снова перекомпилируем ядро. Естественно, с профилированием. Перезагрузившись, повторяем уже известные нам действия по созданию файлов gmon.out и gprof.out. И переходим к анализу полученных файлов. В данном случае результат сразу бросается в глаза, вот что у меня получилось в gprof.out, раздел Flat profile:
Сравним получившиеся результаты функции check_exec с теми, которые были получены до модификации последней. До:
После:
Разница, я думаю, всем понятна. А теперь представим, что изменения, аналогичные тем, что мы специально добавили в систему для уменьшения производительности, попали в код случайно, например, вследствие ошибки программиста. Без профилирования, как мне кажется, будет сложно узнать, что именно «притормаживает» систему. А какие перспективы открывает профилирование для оценки оптимизации кода ядра! Внесли некоторые изменения в процедуру, погоняли машину в тестовом режиме, сравнили результаты с тем, что было в старом варианте и что получилось в новом. И все видно сразу как на ладони. Для любителей оптимизации и разработчиков встроенных систем это просто находка! Вообще тема профилирования достаточно обширна, но думаю, что описанного выше простого примера вполне достаточно, чтобы понять принцип профилирования ядра. |
АЛЕКСАНДР БАЙРАККомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
