Por que o agendador do Linux coloca dois threads no mesmo núcleo físico nos processadores com HyperThreading?

Eu li em vários lugares que o agendador padrão do Linux éconsciente de hyperthreading em máquinas com vários núcleos, o que significa que, se você tiver uma máquina com 2 núcleos reais (4 HT), ela não agendará dois encadeamentos ocupados em núcleos lógicos de uma maneira que ambos executem nos mesmos núcleos físicos (o que levaria a 2x custo de desempenho em muitos casos).

Mas quando eu corrostress -c 2 (gera dois threads para rodar com 100% da CPU) no meu Intel i5-2520M,frequentemente programa (e mantém)os dois encadeamentos nos núcleos HT 1 e 2, que são mapeados para o mesmo núcleo físico. Mesmo que o sistema esteja ocioso de outra maneira.

Isso também acontece com programas reais (estou usandostress aqui porque facilita a reprodução) e, quando isso acontece, meu programa leva o dobro do tempo para ser executado. Configurando afinidade manualmente comtaskset corrige isso para o meu programa, mas eu esperaria que o agendador com suporte a HT fizesse isso corretamente sozinho.

Você pode encontrar oHT-> núcleo físico avaliação comegrep "processor|physical id|core id" /proc/cpuinfo | sed 's/^processor/\nprocessor/g'.

Então, minha pergunta é: Por que o agendador coloca meus threads no mesmo núcleo físico aqui?

Notas:

Esta questão é muito semelhante a estaoutra questão, as respostas às quais dizem queO Linux possui um agendador de encadeamentos sofisticado que reconhece HT. Como descrito acima, não posso observar esse fato (verifique você mesmo comstress -c) e gostaria de saber o porquê.Sei que posso definir a afinidade de processadores manualmente para meus programas, por exemplo com otaskset ferramenta ou com osched_setaffinity função. Não é isso que estou procurando, espero que o planejador saiba por si só que mapear dois threads ocupados para um núcleo físico e deixar um núcleo físico completamente vazio não é uma boa ideia.Estou ciente de que existemalgumas situações em que você prefere que os threads sejam agendados no mesmo núcleo físico e deixem o outro núcleo livre, mas parece absurdo que o planejador faça isso em aproximadamente 1/4 dos casos. Parece-me que os núcleos HT que ele escolhe são completamente aleatórios, ou talvez aqueles núcleos HT que tiveram menos atividade no momento do agendamento, mas que não teriam muito conhecimento de hyperthreading, dada a clareza de programas com as características destress se beneficiam da execução em núcleos físicos separados.

questionAnswers(3)

yourAnswerToTheQuestion