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

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

[2015-08-17 10:20:14 WARNING] dmesg seems to have changed! Diff follows:
--- 2015-08-17 09:55:00
+++ 2015-08-17 10:20:14
@@ -825,3 +825,4 @@
 [    3.802206] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
 [    7.900533] r8169 0000:06:00.0 eth0: link up
 [    7.900541] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
+[236832.221937] perf interrupt took too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 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?

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

EDIT2: после дополнительного чтения я решил, что могу установить kernel.perf_event_max_sample_rate к нулю. Т.е. нет выборок в секунду. Однако и этого сделать нельзя (источник):

commit 02f98e3e36da106338b7c732fed516420fb20e2a
Author: Knut Petersen 
Date:   Wed Sep 25 14:29:37 2013 +0200

perf: Enforce 1 as lower limit for perf_event_max_sample_rate

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

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

Если я действительно не могу отключить перфоманс, вероятно, лучшим компромиссом было бы установить perf_event_max_sample_rate к 1.

EDIT4: друг предположил, что я, возможно, неверно истолковал значение perf_cpu_time_max_percent, поэтому приведенные выше утверждения могут быть неверными. Значение 25 указывает, что ядро ​​использовало более 25% произвольной длины, зарезервированной для обслуживания прерываний производительности.

РЕДАКТИРОВАТЬ5:

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

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

Если вы ориентируетесь на X86 или ...

Я только что проверил, что таргетинг X86_64 действительно позволяет CONFIG_X86. Кажется, что как только вы нацеливаетесь на X86 или X86_64, вы получаете perf.

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

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

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