No meu programa, tenho vários threads que são iniciados junto com o processo e que permanecem até o final do programa. Eles atenderão a cargas diferentes durante a vida útil do aplicativo e, às vezes, todos funcionarão a 100%.
Por padrão, o agendador de threads do Linux mudará a afinidade em um sistema multi-core para esses threads de maneira bastante frívola, IMO. Quando olho para os gráficos saltados em meu monitor de processo gráfico (aquele no gnome), não posso deixar de pensar que isso constitui algum tipo de sobrecarga.
EDITAR:Para esclarecer, mesmo para cargas muito estáveis, os threads são escalonados em núcleos diferentes, e mesmo que não seja visível na imagem, às vezes fica muito claro que o núcleo selecionado para cada thread é "trocado" frequentemente.
Essa mudança constante na afinidade não afetará negativamente o desempenho?
Nesse caso, por que é implementado dessa forma? Quais são os benefícios da mudança de afinidade?
Meus palpites são:
- Nivelamento de desgaste – Não coloque todo o trabalho em um único núcleo
- Não intencional - algum algoritmo inteligente tenta otimizar o uso dependendo da carga e acontece que a sobrecarga não é significativa o suficiente para garantir a manutenção da afinidade ao alterá-la.
Responder1
Se você pretende executar todos os threads em um núcleo, compre hardware mais barato com um único núcleo.
O escalonador tenta aproveitar ao máximo todos os núcleos. Isso significa despachar threads para qualquer núcleo que tenha algum tempo livre. Mover um thread de um núcleo para outro tem um custo pequeno, então o escalonador tenta evitar isso. Mas normalmente você não notará muito isso, porque o benefício de não deixar um núcleo ficar ocioso é muito maior do que o custo de migração de um thread. Isso é especialmente verdadeiro se os threads usarem mais memória do que o cache local do núcleo: se a memória usada por um thread não estiver no cache local do núcleo, há muito pouco a ser perdido ao migrá-lo para outro núcleo.
Adivinhar um agendador de nível industrial como o do Linux geralmente piora o desempenho.
Os gráficos que você mostra indicam que a carga nos vários núcleos não está completa e é levemente variável, provavelmente porque seu sistema como um todo é limitado pela E/S para as tarefas que está executando no momento, e não pela potência da CPU. Não diz nada sobre a frequência com que os threads se movem de um núcleo para outro.
Responder2
O instantâneo fornecido aqui também depende do tipo (versão) do kernel. Kernels mais antigos com versão 2.4 tinham baixa afinidade, o que causava muitos movimentos de threads de pingue-pongue, impactando o desempenho do sistema. As versões do kernel 2.5 têm afinidade relativamente melhor.
Em um sistema baseado em vários núcleos, a configuração da afinidade pode melhorar o desempenho, evitando a ocorrência de invalidação de cache ao mover um thread entre os núcleos.
No caso de 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 sched_setaffinity/taskset para processo e pthread_setaffinity_np para thread.
kernelsharkparece fornecer uma melhor representação visual do sistema multi-core e afinidade.
Além disso, observe quehtopforneça suporte visual para definir afinidade (para substituir o agendador).