Estou procurando uma maneira de obter uma medição de tempo consistente (& lt; 1% de diferença entre as diferentes execuções) para o meu programa no Ubuntu 14.04. perf stat mostra que ainda consigo algumas opções de contexto, embora meu programa nunca controle o sistema operacional (sem E / S, sem alocação de memória, etc.). Eu executo o programa usando sudo nice -n -20 em uma CPU blindada (meu Intel i7 CPU tem quatro núcleos físicos, o hyper-threading está desabilitado no BIOS) com -k on alternando para cset shield .
Eu entendo que os processos de kernel inamovíveis são a fonte dos switches de contexto. Então, minhas perguntas são: existe uma maneira de configurar a proteção na inicialização, para que esses processos inabaláveis sejam executados nos processadores não blindados para começar? No caso em que a resposta é "não", existe outra maneira de obter um ambiente puro para o meu processo crítico no Ubuntu?
Vou mostrar aqui que isso não é possível no Linux em geral.
Em sistemas SMP, há um agendador em execução em cada núcleo, e é por isso que você ainda está recebendo as alternâncias de contexto. Se sua aplicação é realmente crítica, talvez você deva usar algum tipo de RTOS, ao invés de linux.
Dê uma olhada no pacote schedtool. Ele oferece recursos de bloqueio de CPU e uma opção de agendadores de CPU para o usuário.
Preocupado com a GUI afetando as coisas? De um terminal virtual, mate X e veja. Provavelmente com um processador i7, há núcleos suficientes para torná-lo irrelevante. É tudo uma questão de controlar recursos compartilhados, com a CPU sendo apenas um desses recursos. Alguns recursos são tão abundantes que é difícil lembrar que eles são compartilhados, como a memória. Quanto mais você garantir que o seu "processo crítico" não seja atrasado por qualquer outra coisa, pior o seu sistema operacional Linux geral se comportará a partir de um ponto de vista de interação do usuário.
Não sei o que você quer dizer com processadores não blindados, mas a maneira de atribuir qualquer processo a uma CPU é usar o taskset . Você pode até usá-lo nos módulos do kernel para forçar a política bruta do NUMA.
Quando eu quero executar para executar experimentos comparáveis I: Bloqueie as freqüências de relógio da CPU ou o regulador, de modo a evitar possíveis diferenças de resposta; Forçar a tarefa para executar em uma CPU específica (se não for multi-threaded); Se houver alguma E / S de disco envolvida ou qualquer outra fonte de armazenamento em cache, libere o cache de memória entre execuções para uma comparação justa.
Para meus experimentos que sempre foram bons o suficiente, mas talvez não para os seus. Vou editar isso com mais detalhes, se desejar.
Edit: eu esqueci de mencionar e muito importante. Eu só uso a edição do servidor Ubuntu para este tipo de trabalho. Os desktops têm muitas outras coisas sempre em execução. e assim um computador "ocioso" de outra forma realmente não é onde está ocioso. Em um servidor inativo, há apenas o trabalho ocasional do cron, que pode atrapalhar a execução do experimento.
Por exemplo, eu fiz 262 execuções de um programa que leva em média 5,6217 segundos para executar. O desvio padrão do tempo de execução foi 0,0119 segundos e os piores casos foram + 0,68% e -0,56%. Forcei a CPU 7 e o modo de desempenho forçado (mas note que, mesmo no modo de desempenho, os processadores Intel i7 podem diminuir a freqüência de clock sozinhos).
Além disso, se eu desabilitar o governador de freqüência intel_pstate e usar o acpi_cpufreq no modo "powersave", basicamente bloqueando as CPUs no pstate mínimo (frequência mais baixa), então recebo cerca de +/- 0,01% de variações de tempo de execução em um tempo médio de execução de 13,22 segundos.