Практика работы с 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, это список всех вызванных функций, время и количество их вызовов.

Вот пример части вывода:

Дальше в том же духе. Давайте рассмотрим содержание этих столбцов более подробно.

1. Сколько всего времени (в процентах) исполнялась та или иная функция.
2. Общая сумма времени (в секундах) выполнения всех функций до текущего момента.
3. Время (в секундах) исполнения какой-либо функции. Это основной показатель данной таблицы.
4. Общее количество вызовов некой функции.
5. Среднее время (в миллисекундах), истраченное на вызов функции. Если функция не профилируется, то столбец останется пустым. Например, функцию idle, как вы понимаете, «улучшить» никак нельзя, поэтому текущий столбец для этой функции оказался незаполненным.
6. Среднее время (в миллисекундах), истраченное этой функцией и ее потомками на вызов. Так же, как и в предыдущем столбце, если функция не профилируется, значение остается пустым.
7. Имя функции.

Как видно из этого фрагмента, подавляющее большинство времени система бездействовала.

Теперь следует раздел Call Graph Profile. Его задача – показать дальнейшие запросы («потомки») от перечисленных функций.

Вот часть вывода:

И так далее. Всего 6 столбцов с данными.

1. Уникальное число, присвоенное каждой функции.
2. Cколько времени (в процентах) исполнялась некая функция и все ее «потомки».
3. Общий процент времени, истраченный на эту функцию.
4. Общее время, занятое «потомками» этой функции.
5. Сколько раз функция была вызвана. После «/» идет количество вызовов этой функции ее потомками. Рекурсивные вызовы не учитываются.
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 с теми, которые были получены до модификации последней.

До:

После:

Разница, я думаю, всем понятна. А теперь представим, что изменения, аналогичные тем, что мы специально добавили в систему для уменьшения производительности, попали в код случайно, например, вследствие ошибки программиста. Без профилирования, как мне кажется, будет сложно узнать, что именно «притормаживает» систему. А какие перспективы открывает профилирование для оценки оптимизации кода ядра! Внесли некоторые изменения в процедуру, погоняли машину в тестовом режиме, сравнили результаты с тем, что было в старом варианте и что получилось в новом.

И все видно сразу как на ладони. Для любителей оптимизации и разработчиков встроенных систем это просто находка!

Вообще тема профилирования достаточно обширна, но думаю, что описанного выше простого примера вполне достаточно, чтобы понять принцип профилирования ядра.

Комментарии могут оставлять только зарегистрированные пользователи