Desative a opção do kernel [HAVE_PERF_EVENTS] e recompile o kernel do Linux.
Estou executando alguns benchmarks. Meu benchmark monitora o buffer do dmesg entre os experimentos, procurando por qualquer coisa que possa afetar o desempenho. Hoje ele jogou isso:
[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
Após algumas pesquisas, agora sei que isso se relaciona a um subsistema de criação de perfil no kernel do Linux chamado "perf". Eu não acho que precisamos disso, então eu gostaria de desativá-lo completamente.
Pesquisando novamente, acho que o sysctl perf_cpu_time_max_percent
poderia ajudar. Aqui alguém sugere desabilitar definindo-o como 0. Lendo para isso mais algumas aqui :
perf_cpu_time_max_percent:
Hints to the kernel how much CPU time it should be allowed to use to handle perf sampling events. If the perf subsystem is informed that its samples are exceeding this limit, it will drop its sampling frequency to attempt to reduce its CPU usage.
Some perf sampling happens in NMIs. If these samples unexpectedly take too long to execute, the NMIs can become stacked up next to each other so much that nothing else is allowed to execute.
0: disable the mechanism. Do not monitor or correct perf's sampling rate no matter how CPU time it takes.
1-100: attempt to throttle perf's sample rate to this percentage of CPU. Note: the kernel calculates an "expected" length of each sample event. 100 here means 100% of that expected length. Even if this is set to 100, you may still see sample throttling if this length is exceeded. Set to 0 if you truly do not care how much CPU is consumed.
Isso soa como 0 significa que a taxa de amostragem de criação de perfil não está mais marcada, mas o subsistema de frequência permanece em execução (?).
Alguém pode esclarecer como desabilitar completamente o perfil do kernel com a freq?
EDIT: Alguém sugeriu que eu tente construir um kernel sem perf, mas eu não acho que isso seja possível. A opção não parece comutável:
EDIT2:Depoisdelermais,decidiquepoderiadefinirkernel.perf_event_max_sample_rate
parazero.Ousejasemamostrasporsegundo.Noentanto,vocênãopodefazerisso(
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
EDIT 3: FWIW, perf_cpu_time_max_percent
é definido como 25, o que significa que o kernel estava gastando mais de 25% dos registros de hardware de amostragem de tempo. Isso é inaceitável para uma máquina de benchmarking.
Agora estou certo de que configurar perf_cpu_time_max_percent
para zero só pioraria a situação, já que o kernel continuaria a usar mais de 25% do tempo de leitura de registros de hardware. O erro é acionado para ajustar a taxa de amostragem, tentando garantir que o kernel atinja sua cota de uso de < 25% de seu tempo em perf. 25% ainda é IMHO muito alto.
Se eu realmente não puder desabilitar o perf, provavelmente o melhor compromisso seria definir perf_event_max_sample_rate
para 1.
EDIT4: Um amigo sugeriu que eu possa ter interpretado erroneamente o significado de perf_cpu_time_max_percent
, então as declarações acima podem estar incorretas. Um valor de 25 indica que o kernel usou mais de 25% de algum tamanho arbitrário que ele reservou para manutenção de interrupções de desempenho.
EDIT5:
Como apontado nos comentários, a opção -*-
contra o perf sugere que o recurso é forçado por outro recurso ativado. Se eu olhar em help
, ele diz quais recursos são:
Eu não acho que posso ganhar aqui. A fórmula booleana selected by
diz
If you are targeting X86, or...
Acabei de verificar que a segmentação X86_64 habilita CONFIG_X86
. Assim, parece que assim que você direcionar X86 ou X86_64, você obtém o desempenho.
Por isso, gostaria de alterar ligeiramente a minha pergunta para:
Which perf settings can I use to minimise the time spent by the kernel in perf routines?
Tenha em mente que o objetivo geral é controlar fontes de variação aleatória para benchmarking. Se eu não posso desabilitar o perf, como posso minimizar o impacto nos benchmarks?
Desative a opção do kernel [HAVE_PERF_EVENTS] e recompile o kernel do Linux.