Ligação Linux com desempenho fraco de LAN de 2x10G em kernels após 4.13.x

Question

Aqui está nossa configuração de um servidor DELL com duas portas LAN 10G e nosso antigo kernel 4.13.4 servindo conteúdo de vídeo estático usando nginx (~ 8000 conexões ativas) com a largura de banda em torno de 15.5G (1.2Mpps) no pico. Usamos o kernel de baixa latência do Ubuntu construído a partir do link sem nenhuma alteração na configuração padrão (pela simplicidade desse problema ), que vem com os patches debian / ubuntu.
Então pegamos o novo kernel na época 4.18.8 e construímos da mesma forma que fizemos com o 4.13.x ano passado, mas foi uma grande falha . O desempenho da ligação foi muito ruim, a rede não passou 10.5G no pico sem ser mais carregada do que com o kernel antigo 4.13.4 - coletamos estatísticas do sistema e da rede a cada 10 segundos e a carga e o IO são quase os mesmos mesmo - não há problema com o IO dos discos, que são alguns SSDs. Tentamos rastrear o problema - tentamos o 4.14.x (4.14.10 antes da ativação do espectro e da fusão), 4.17.xe 4.18.x com e sem o espectro e a fusão ativados (aqueles que poderíamos desativar). Basicamente, temos um desempenho melhor com quase ~ 10% de 4.17.xe 4.18.x sem espectro e derretimento (aqueles que poderíamos desligar) e quase a mesma velocidade com 4.14.10 (ainda não é o mesmo com 4.13). Usamos a seguinte linha para desativar tudo que pudermos do espectro e da fusão:

nospectre_v1 nospectre_v2 nospec_store_bypass_disable ssbd=force-off kvm-intel.vmentry_l1d_flush=never l1tf=off nopti no_rfi_flush kpti=off noibrs noibpb nospec no_stf_barrier

Mas spectre_v1 e l1tf não podem ser desativados , mesmo que haja opções para isso. Com a linha acima, a rede do kernel 4.14.70 é 20% melhor (do que sem ela, mas ainda muito pior do que deveria ser), mas com o kernel 4.18.12 (e 4.18.8) é quase o mesmo desempenho ruim. br> Durante os testes de todos os kernels, não alteramos nenhuma outra opção em nosso servidor e temos um sistema de automação, que verifica as diferenças, portanto, temos certeza de que todas as opções personalizadas que alteramos (no sistema) são aplicadas durante a inicialização. Nossa configuração de ligação é:

bond-mode 4
bond-miimon 100
bond-lacp-rate slow
bond-slaves eth4 eth5
bond-xmit_hash_policy layer3+4
bond-downdelay 200
bond-updelay 200

Alguém experimenta esse comportamento e como podemos prosseguir com mais depuração? IS esta degradação do desempenho do espectro e da fusão (realmente -50% ??)? Poderia ser de uma opção padrão alterada nos kernels após o 4.13 (embora tenhamos verificado a diferença da configuração padrão e entre 4.14 e 4.13 e não há tantas mudanças lá e nós tentamos). Nós também tentamos o kernel 4.14.10 - pouco antes da ativação do código de espectro e fusão (provavelmente o código está no kernel, de fato) e ainda não conseguimos alcançar o desempenho do kernel 4.13.x embora tenhamos conseguido arquivar quase 90% do kernel. isto. Fizemos um svg com o FlameGraph de registro perf:

perf record -F 99 -ag -- sleep 60

E os kernels de 4.13.4 a 4.18.12 diferem realmente em quanto tempo os kernels estão em função relacionados à pilha de rede. Com o mesmo tráfego e carga sobre o servidor, o tempo gasto pelo kernel para funções relacionadas à pilha de rede é significativamente menor em 4.13.4 do que em 4.18.12 e é como uma degradação gradual em relação às versões mais recentes dos kernels.