Как отключить подсистему perf в ядре Linux?

Я запускаю несколько тестов. Мой тестовый прогон контролирует буфер dmesg между экспериментами, ища что-нибудь, что может повлиять на производительность. Сегодня это бросило это:

[2015-08-17 10:20:14 ВНИМАНИЕ] dmesg, похоже, изменился! Diff следует:
--- 2015-08-17 09:55:00
+++ 2015-08-17 10:20:14
@@ -825,3 +825,4 @@
 [3.802206] [drm] Включение состояний RC6: RC6 включен, RC6p выключен, RC6pp выключен
 [7.900533] r8169 0000: 06: 00.0 eth0: соединение
 [7.900541] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: ссылка становится готовой
+ [236832.221937] perf прерывание заняло слишком много времени (2504> 2500), в результате чего kernel.perf_event_max_sample_rate снизилось до 50000

После некоторого поиска я теперь знаю, что это относится к подсистеме профилирования в ядре linux, называемой «perf». Я не думаю, что нам это нужно, поэтому я бы хотел отключить его вообще.

Поиск снова, я обнаружил, что sysctl perf_cpu_time_max_percentможет помочь. Здесь кто-то предлагает отключить, установив его на 0. Подробнее об этом читаем здесь :

perf_cpu_time_max_percent:

Подсказывает ядру, сколько процессорного времени должно быть разрешено использовать для обработки событий выборки. Если подсистеме perf сообщают, что ее выборки превышают этот предел, она будет снижать частоту дискретизации, чтобы попытаться уменьшить загрузку своего ЦП.

Некоторая отбор проб происходит в НМИ. Если эти образцы неожиданно выполняются слишком долго, NMI могут быть сложены рядом друг с другом настолько, что ничто другое не может быть выполнено.

0: отключить механизм. Не контролируйте и не корректируйте частоту дискретизации perf независимо от того, сколько времени занимает процессор.

1-100: попытка снизить частоту дискретизации perf до этого процента CPU. Примечание: ядро ​​вычисляет «ожидаемую» длину каждого примера события. 100 здесь означает 100% этой ожидаемой длины. Даже если для этого параметра установлено значение 100, при превышении этой длины вы все равно можете увидеть дросселирование образца. Установите в 0, если вам действительно все равно, сколько процессора потребляется.

Это звучит для меня как 0 означает, что частота выборки профилирования больше не проверяется, но подсистема freq продолжает работать (?).

Может кто-нибудь пролить свет на то, как полностью отключить профилирование ядра с помощью freq?

РЕДАКТИРОВАТЬ: Кто-то предложил мне попробовать собрать ядро ​​без Perf, но я не думаю, что это даже возможно. Опция не кажется переключаемой:

РЕДАКТИРОВАТЬ 2: После дополнительного чтения, я решил, что смогу установить kernel.perf_event_max_sample_rateна ноль. Т.е. нет образцов в секунду. Тем не менее, вы также не можете сделать это ( источник ):

commit 02f98e3e36da106338b7c732fed516420fb20e2a
Автор: Кнут Петерсен 
Дата: ср 25 сен 14:29:37 2013 +0200

perf: использовать 1 как нижний предел для perf_event_max_sample_rate

РЕДАКТИРОВАТЬ 3: FWIW, perf_cpu_time_max_percentустановлен в 25, что означает, что ядро ​​тратит более 25% своего времени на выборку аппаратных регистров. Это неприемлемо для бенчмаркинга.

Теперь я уверен, что установка perf_cpu_time_max_percentна ноль только ухудшит ситуацию, поскольку ядро ​​будет продолжать использовать более 25% времени для чтения аппаратных регистров. Ошибка срабатывает, чтобы настроить частоту дискретизации, таким образом, пытаясь убедиться, что ядро ​​соответствует своей квоте использования <25% своего времени в perf. 25% все еще слишком высоко ИМХО.

Если я действительно не могу отключить perf, возможно, лучшим компромиссом будет установить perf_event_max_sample_rate1.

РЕДАКТИРОВАТЬ 4: друг предположил, что я, возможно, неправильно истолковал значение perf_cpu_time_max_percent, поэтому приведенные выше утверждения могут быть неверными. Значение 25 указывает, что ядро ​​использовало более 25% произвольной длины, которую оно зарезервировало для обслуживания прерываний perf.

EDIT5:

Как указано в комментариях, -*-опция « против перфорации» предполагает, что эта функция включена другой включенной функцией. Если я загляну help, там написано, что это за функции:

Я не думаю, что смогу выиграть здесь. Булева формула selected byговорит

Если вы нацелены на X86 или ...

Я только что проверил, что нацеленность на X86_64 действительно включена CONFIG_X86. Таким образом, кажется, что как только вы нацеливаетесь на X86 или X86_64, вы получаете перф.

Поэтому я хотел бы немного изменить свой вопрос на:

Какие настройки perf можно использовать, чтобы минимизировать время, затрачиваемое ядром на perf процедуры?

Имейте в виду, что общая цель состоит в том, чтобы контролировать источники случайных отклонений для сравнительного анализа. Если я не могу отключить перфект, как я могу минимизировать его влияние на тесты?

Отключите опцию ядра [HAVE_PERF_EVENTS] и перекомпилируйте ядро ​​Linux.