On Thu, 01 Sep 2011, Cleber Ianes wrote: > Muito obrigado Fabricio. > É exatemente isso que preciso, agora já tenho o "caminho" a seguir.
Seguem mais umas dicas: 0. Portar uma aplicação com elevado paralelismo para rodar em GPU, quando possível, é praticamente a única resposta correta. O aumento de performance é medido em ordens de grandeza. 1. Use o hwloc para sempre amarrar o processo em todos os irmãos HT ao mesmo tempo. E use o hwloc para amarrar o resto do sistema para longe daquele core e de todas as suas threads. *Não* toque nos processos do kernel a menos que saiba o que está fazendo, alguns precisam poder rodar na mesma CPU que o seu processo para melhor performance em algumas syscalls. Você quer que o processo possa rodar em todas as threads do core, e quer manter outros processos longe de todas as threads do core. O objetivo é manter os caches L2 e L3 do core quentes com o que o processo precisa. Dá para fazer tudo isso para cada thread do processo se necessário, mas se você entregar várias "CPUs" para o processo, o kernel vai espalhar as threads dele em todas essas CPUs sozinho. 2. Se o equipamento for NUMA (e se for servidor recente com mais de um soquete, as chances são enormes de que seja), configure o BIOS/ UEFI corretamente e use o numactl e o hwloc para aumentar a afinidade do processo com a memória mais perto do processador onde ele irá rodar. 3. A única forma de ter certeza que você fez o que é melhor para a sua aplicação é testando. 4. Se o processo faz muito IO de rede, pode ser necessário trabalhar também na afinidade das interrupções. 5. Use um equipamento próprio para HPC se puder, e coloque tudo no BIOS/UEFI para "performance", na tentativa de evitar que o firmware fique desperdiçando performance fazendo besteira em SMM. 6. Use o schedtool para mudar o modelo de scheduling do processo para o quer for realmente correto para ele. Provavelmente SCHED_BATCH. 7. Leve em conta a CPU que tem. Se o processo não precisa de todos os cores, e o resto do sistema também não, é possível que desativá-los permita que o auto-overclock de uma CPU Intel suba a performance da aplicação, ou que diminua a pressão nos caches L3 ou a quantidade de mensagens inter-CPU (IPIs). Tem um utilitário não empacotado, o turbostat, distribuido no fonte dos kernel mais novos, capaz de medir o "turbo mode" dos Intel. AMD tem suas peculiaridades que são bem diferentes das dos Intel. Infelizmente não as conheço bem para listar aqui. 8. Tudo isso (exceto a regra "0") não vai aumentar a performance de forma estrodosa, a menos que tenha algo de muito errado para começo de história, ou seja, muitas vezes não vale o esforço. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110901200458.ga12...@khazad-dum.debian.net
