¿Cómo deshabilitar el subsistema perf en el kernel de Linux?

Estoy ejecutando algunos puntos de referencia. Mi corredor de referencia monitorea el búfer dmesg entre experimentos, buscando cualquier cosa que pueda afectar el rendimiento. Hoy arrojó esto:

[2015-08-17 10:20:14 ADVERTENCIA] dmesg parece haber cambiado! Diff sigue:
--- 2015-08-17 09:55:00
+++ 2015-08-17 10:20:14
@@ -825,3 +825,4 @@
 [3.802206] [drm] Habilitación de los estados RC6: RC6 encendido, RC6p apagado, RC6pp apagado
 [7.900533] r8169 0000: 06: 00.0 eth0: enlace arriba
 [7.900541] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: el enlace está listo
+ [236832.221937] la interrupción del rendimiento tardó demasiado (2504> 2500), reduciendo kernel.perf_event_max_sample_rate a 50000

Después de algunas búsquedas, ahora sé que esto se relaciona con un subsistema de creación de perfiles en el núcleo de Linux llamado "perf". No creo que necesitemos esto, así que me gustaría deshabilitarlo por completo.

Buscando de nuevo, encuentro que el sysctl perf_cpu_time_max_percentpodría ayudar. Aquí alguien sugiere desactivarlo configurándolo en 0. Leyendo esto un poco más aquí :

perf_cpu_time_max_percent:

Le sugiere al kernel cuánto tiempo de CPU debería permitirse usar para manejar eventos de muestreo de rendimiento. Si se informa al subsistema de rendimiento que sus muestras están excediendo este límite, disminuirá su frecuencia de muestreo para intentar reducir su uso de CPU.

Parte del muestreo de rendimiento ocurre en los INM. Si estas muestras tardan demasiado en ejecutarse inesperadamente, los NMI se pueden apilar uno al lado del otro tanto que no se permite ejecutar nada más.

0: deshabilitar el mecanismo. No controle ni corrija la frecuencia de muestreo de perf sin importar el tiempo de CPU que tome.

1-100: intente reducir la frecuencia de muestreo de perf a este porcentaje de CPU. Nota: el núcleo calcula una longitud "esperada" de cada evento de muestra. 100 aquí significa el 100% de la longitud esperada. Incluso si se establece en 100, es posible que vea una aceleración de la muestra si se excede esta longitud. Establezca a 0 si realmente no le importa la cantidad de CPU que se consume.

Esto me parece que 0 significa que la frecuencia de muestreo de perfil ya no se verifica, pero el subsistema freq sigue ejecutándose (?).

¿Alguien puede arrojar luz sobre cómo deshabilitar completamente el perfil del kernel con freq?

EDITAR: Alguien sugirió que intente construir un kernel sin perf, pero no creo que esto sea posible. La opción no parece conmutable:

EDIT2: Después de leer más, decidí que podría establecerlo kernel.perf_event_max_sample_rateen cero. Es decir, no hay muestras por segundo. Sin embargo, tampoco puedes hacer esto ( fuente ):

cometer 02f98e3e36da106338b7c732fed516420fb20e2a
Autor: Knut Petersen 
Fecha: miércoles 25 de septiembre 14:29:37 2013 +0200

perf: Aplicar 1 como límite inferior para perf_event_max_sample_rate

EDIT 3: FWIW, perf_cpu_time_max_percentestá configurado en 25, lo que significa que el núcleo estaba gastando más del 25% de su tiempo muestreando registros de hardware. Esto es inaceptable para una máquina de evaluación comparativa.

Ahora estoy seguro de que establecerlo perf_cpu_time_max_percenten cero solo empeoraría la situación, ya que el núcleo continuaría usando más del 25% de su tiempo leyendo registros de hardware. El error se dispara para ajustar la frecuencia de muestreo, tratando de garantizar que el núcleo cumpla con su cuota de uso de <25% de su tiempo en rendimiento. 25% sigue siendo demasiado alto en mi humilde opinión.

Si realmente no puedo desactivar el rendimiento, probablemente el mejor compromiso sería establecerlo perf_event_max_sample_rateen 1.

EDITAR4: Un amigo sugirió que podría haber malinterpretado el significado de perf_cpu_time_max_percent, por lo que las declaraciones anteriores pueden ser incorrectas. Un valor de 25 indica que el núcleo usó más del 25% de alguna longitud arbitraria que había reservado para dar servicio a las interrupciones de rendimiento.

EDITAR5:

Como se señaló en los comentarios, la -*-opción en contra de perf sugiere que la característica es forzada por otra característica habilitada. Si miro help, dice qué características son estas:

No creo que pueda ganar aquí. La fórmula booleana selected bydice

Si está apuntando a X86, o ...

Acabo de comprobar que la segmentación X86_64 sí está habilitada CONFIG_X86. Entonces parece que tan pronto como apuntas a X86 o X86_64, obtienes rendimiento.

Entonces me gustaría cambiar ligeramente mi pregunta a:

¿Qué configuración de rendimiento puedo usar para minimizar el tiempo que el núcleo dedica a las rutinas de rendimiento?

Tenga en cuenta que el objetivo general es controlar las fuentes de variación aleatoria para la evaluación comparativa. Si no puedo desactivar el rendimiento, ¿cómo puedo minimizar su impacto en los puntos de referencia?

Deshabilite la opción del kernel [HAVE_PERF_EVENTS] y vuelva a compilar el kernel de Linux.