[GTER] Ethernet Hyper Threading...

[Henrique de Moraes Holschuh]

On 06-09-2012 16:08, Lucas Willian Bocchi wrote:
> Não fez isso no meu kernelo 3.5.3 Henrique.

Bom, então vai precisar ajustar manualmente as affinities (ou via
irqbalance).  O MSI-X entrega cada vetor de interrupção [do mesmo
dispositivo] direto para o core que você setar nas affinities, coisa que
com MSI só dá para fazer via IOMMU (e em Linux não dá para fazer sem patch).

Preciso dar uma olhada se fiz alguma coisa para o próprio kernel tentar
balancear interrupções, ou se rodei irqbalance em todos os servidores.
Pode realmente ser que precise uma configuração inicial de affinities em
todos os casos.

> Tive que fazer um shell script pra jogar nos cores. Pelo menos não
> aparecia antes de rodar o script assim da forma separada que eu te
> mandei.

Ok.

> Sim, no primeiro caso. Mas depois na 3com que é pci você pode ver que
> ele vai pro segundo core da máquina mesmo sendo uma placa PCI.

Os APICs e LAPICs modernos permitem entregar qualquer linha de
interrupção em um core específico (ou em vários deles via round-robin).

Mas nesse caso, o APIC vai entregar *todas* as interrupções naquela
linha de interrupção para esses cores no affinity.  Como são poucas
linhas de interrupção, é comum ter mais de um dispositivo por linha, o
que obriga o kernel a chamar o interrupt handler de cada driver
pendurado ali, resultando em diversos acessos de IO/MMIO que teriam sido
evitados, eventuais bugs em um driver ou dispositivo capotando os
outros, etc.  Mesmo com tudo funcionando que é uma beleza, a latência e
eficiência são péssimas.

MSI resolve isso (mesmo em Linux) garantindo que cada dispositivo terá
seu vetor exclusivo (poderiam ser até 32 vetores para cada dispositivo,
mas Linux não suporta isso.  Não sei o FreeBSD).  Já melhora muito os
problemas de latência e eficiência, pois não há compartilhamento por
vários dispositivos da mesma "linha de interrupção" (MSIs são mensagens,
não envolvem linhas de interrupção no sentido literal).

Só que todas as MSIs do mesmo dispositivo seriam direcionadas para o
mesmo core/conjunto de cores a menos que uma IOMMU no meio do caminho
resolva isso (e desconfio que o faça traduzindo de MSI para MSI-X).  E
se você tem uma IOMMU dessas, você tem suporte a MSI-X na plataforma, e
deveria procurar dispositivos com suporte nativo a MSI-X.  Por isso o
suporte a várias MSI no mesmo dispositivo foi ignorado em Linux por
tanto tempo[1]...

MSI-X não tem nenhuma limitação desse tipo.  O problema com MSI-X é que
ainda não é raro haver bug de hardware no dispositivo, e até algum tempo
atrás, na plataforma.

[1] Mas como tem coisa útil que até hoje não foi atualizado para
suportar MSI-X, como os controladores EHCI, UHCI e AHCI, pode ser que o
suporte à múltiplas MSIs via IOMMU seja adicionado ao Linux.  Vai
depender do que resolverem sobre o custo-benefício, são umas 500 linhas
de código a mais, e ativar um novo modo de operação no hardware (o que
sempre é algo *temerário*).

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.