a afinidade nunca muda atribuída aos threads pelo kernel do Linux terá um efeito adverso no desempenho geral?

1

No meu programa, eu tenho vários threads que são iniciados com o processo e que permanecem até que o programa termine. Eles vão encontrar diferentes cargas durante o tempo de vida do aplicativo e, às vezes, eles serão executados a 100%.

Por padrão, o agendador de encadeamentos do Linux alterará a afinidade em um sistema de vários núcleos para esses encadeamentos de forma bastante frívola. Quando olho para os gráficos saltantes no meu monitor de processo gráfico (o do gnome) não posso deixar de pensar que isso constitui algum tipo de sobrecarga.

EDITAR: Para esclarecer, mesmo para cargas muito estáveis, os encadeamentos são agendados em núcleos diferentes, e mesmo que não seja visível na imagem, às vezes é muito claro que o núcleo selecionado para cada thread é "trocada" com freqüência.

Esta mudança constante na afinidade não afetará negativamente o desempenho?

Nesse caso, por que é implementado dessa maneira? Quais benefícios a afinidade de mudança tem?

Meus palpites são:

  • Nivelamento de desgaste - não coloque todo o trabalho em um só núcleo
  • Não intencional - Algum algoritmo inteligente tenta otimizar o uso dependendo da carga e acontece que a sobrecarga de não é significativa o suficiente para garantir manter a afinidade de alterá-lo.
por Lennart Rolland 09.10.2014 / 23:56

2 respostas

1

Se você for executar todos os segmentos em um só núcleo, compre um hardware mais barato com um único núcleo.

O agendador tenta aproveitar ao máximo todos os núcleos. Isso significa distribuir threads para qualquer núcleo que tenha algum tempo livre. Mover um encadeamento de um núcleo para outro núcleo tem um custo pequeno, portanto, o planejador tenta evitar isso. Mas você normalmente não notará muito, porque o benefício de não deixar um núcleo ficar ocioso é muito mais do que o custo de migrar um thread. Isso é especialmente verdadeiro se os encadeamentos usarem mais memória do que o cache core-local: se a memória usada por um encadeamento não estiver no cache core-local, há muito pouco a perder ao migrá-lo para outro núcleo.

Segundo, um agendador de nível industrial como o Linux geralmente piora o desempenho.

Os gráficos que você mostra indicam que a carga nos vários núcleos não é completa e levemente variável, presumivelmente porque seu sistema como um todo é limitado por E / S para as tarefas que está fazendo agora, não pela energia da CPU. Ele não diz nada de um jeito ou de outro sobre a frequência com que os segmentos se movem de um núcleo para outro.

    
por 10.10.2014 / 03:24
1

O instantâneo fornecido aqui também depende do tipo (versão) do kernel. Os kernels mais antigos com a versão 2.4 tinham pouca afinidade, o que causava grande movimentação de pingue-pongue, causando impacto no desempenho do sistema. Versões de kernel de 2.5 têm afinidade relativamente melhor.

Em um sistema baseado em vários núcleos, a configuração de afinidade pode melhorar o desempenho, evitando a ocorrência de invalidação de cache durante a movimentação de um encadeamento pelos núcleos.

No caso de um sistema multi-core baseado em linux, o comportamento de afinidade do agendador (afinidade natural) pode ser substituído com base no tipo de aplicativo / requisito usando o sched_setaffinity / taskset para o processo e pthread_setaffinity_np para o encadeamento.

kernelshark parece fornecer uma melhor representação visual do sistema multi-core & afinidade.

Além disso, observe que o htop fornece suporte visual para definir a afinidade (para substituir o agendador).

    
por 29.10.2014 / 23:49