Linux Scheduler (não usando todos os núcleos na máquina multi-core) RHEL6

Question

Estou vendo um comportamento estranho em um dos meus servidores (executando o RHEL 6). Parece haver algo errado com o agendador.

Aqui está o programa de teste que estou usando:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

void RunClient(int i) {
  printf("Starting client %d\n", i);
  while (true) {
  }
}

int main(int argc, char** argv) {
  for (int i = 0; i < 4; ++i) {
    pid_t p_id = fork();
    if (p_id == -1) {
      perror("fork");
    } else if (p_id == 0) {
      RunClient(i);
      exit(0);
    }
  }

  return 0;
}

Esta máquina tem muito mais de 4 núcleos, então esperamos que todos os processos estejam rodando a 100%. Quando eu verificar no topo, o uso da CPU varia. Às vezes é dividido (100%, 33%, 33%, 33%), outras vezes é dividido (100%, 100%, 50%, 50%).

Quando eu tento este teste em outro servidor nosso (executando o RHEL 5), não há problemas (é 100%, 100%, 100%, 100%) conforme o esperado. O que está causando isso e como posso corrigi-lo?

Obrigado

    

Answer 1

Você parece estar reinventando a roda, já existem vários programas de tortura da CPU disponíveis, como stress . Aposto que o compilador C otimiza seu programa de tal forma que ele não precisa gravar constantemente a CPU durante o teste.

Tente com

stress -c 4 -t 60

Isso iniciaria 4 processos intensivos da CPU e executaria o teste por 60 segundos. Aposto que você verá quatro núcleos rodando a 100%. Embora se você tiver MUITO mais núcleos do que 4 (digamos, 16), o resultado poderá variar, a menos que você fixe o comando stress para usar núcleos específicos com taskset .

    

Answer 2

Bem, existem grandes diferenças entre Red Hat 5 e 6. Acho que a maior delas que afetaria seu caso de uso é a mudança para o Completely Fair Scheduler. Ele não está quebrado, mas provavelmente exibirá um comportamento diferente no topo em comparação com o planejador no RHEL 5. Ele permitirá que processos que estavam sendo totalmente ignorados anteriormente tenham algum tempo de processamento.

Eu também acho que esse loop while vazio é na maior parte um no-op e será otimizado para o esquecimento se você tivesse algum tipo de otimização ativada para a compilação (eu não sou muito de um programador C mas eu acredito que, para ser o caso, pode até acontecer sem sinalizadores de otimização explícitos, pois é totalmente redundante). Tente colocar alguns cálculos reais lá e ver o que acontece.

Como regra geral, a menos que você saiba o suficiente para escrever seu próprio planejador de kernel, eu diria que não é um bug, mas uma manifestação de como o sistema funciona. Ou um problema com seu código / instrumentação.