Измерение накладных расходов на системные вызовы в Linux

Question

Я искал подходящий метод для измерения стоимости различных системных вызовов в ОС Linux. В прошлом было много вопросов, связанных с этим топи c, но ни один из них не дает подробного описания того, как его точно измерить. В большинстве ответов произвольно утверждается, что стоимость системного вызова составляет 1-2 миллиарда долларов или несколько 100 циклов, если он кэшируется на ЦП.

1. Накладные расходы на системные вызовы
2. Накладные расходы на системные вызовы

Наивный способ, который я могу придумать для измерения стоимости системных вызовов, - это использовать инструкцию rdtscp для системного вызова, такого как getpid (). Однако этого недостаточно для точного измерения стоимости вызовов open (), read () или write (). Я могу изменить ядро ​​и вставить специальный код таймера c в эти функции и измерить его, но это потребует изменений в ядре, которых я не хочу делать. Интересно, есть ли более простое решение, которое позволило бы мне измерить его из самого пользовательского пространства.

Обновление: 14 июля: после долгих поисков я нашел набор тестов libmicro от RedHat. https://github.com/redhat-performance/libMicro

Однако это создается некоторое время как go, и мне интересно, насколько это хорошо. Конечно, он не использует rdtscp, что добавляет некоторые ошибки измерения. Есть ли что-нибудь еще, чего не хватает при создании этого теста?

Answer 1

strace и perf обычно используются для отслеживания и измерения таких операций (ядра). В частности, perf можно использовать для генерации графиков пламени, позволяющих видеть подробные вызовы функций в ядре. Однако следует помнить, что необходимо настроить соответствующие права в /proc/sys/kernel/perf_event_paranoid.

Я советую вам поместить системный вызов в al oop, так как точное измерение стоимости одного системного вызова с возможной задержкой / асинхронной работой в потоки ядра либо очень сложно измерить в пространстве пользователя, либо просто неточно (в ненастроенном ядре).

Дополнительная информация:

strace работать с микросекундной гранулярностью. Некоторые тактовые частоты POSIX (см. clock_gettime) могут достигать шага 100 нс. За пределами этого предела rdtscp является одним из самых точных, AFAIK (нужно учитывать опорную частоту). Что касается perf, он использует аппаратные счетчики производительности и события ядра. Возможно, вам потребуется настроить ядро ​​так, чтобы точки трассировки могли генерироваться и правильно отслеживаться perf. perf может отслеживать один конкретный c процесс или всю систему.