Confira !!
O principal desenvolvedor do DragonFlyBSD, Matthew Dillon, vem reformulando a infraestrutura de memória virtual (VM) dentro de seu kernel e está levando a melhorias de desempenho mensuráveis.
Esta postagem da lista de discussão descreve o trabalho em torno do código pmap da máquina virtual do kernel que está sendo reestruturado, o que resulta em possível conservação da memória, ajuda nos processos que compartilham muita memória e melhora o desempenho de falhas de página simultâneas. Os bits de performance são o que buscamos e eles parecem ser bastante atraentes, pelo menos com os testes de Dillon até agora em sistemas de teste grandes (Threadripper) e pequenos (Raven Ridge) da AMD:
Essas alterações melhoram significativamente o desempenho de falhas de página, especialmente sob cargas simultâneas pesadas.
* A sobrecarga do kernel durante a compilação em massa 'synth everything' está agora abaixo de 15% do tempo do sistema. Costumava ser mais de 20%. (hora do sistema / (hora do sistema + tempo do usuário)). Testado no threadripper (32-core / 64-thread).
* O uso pesado de mmap () s compartilhados entre processos não multiplica mais o uso pv_entry, economizando muita memória. Isso pode ser particularmente importante para postgres.
* Faltas simultâneas de página agora não têm, essencialmente, nenhuma contenção de bloqueio de SMP e apenas quatro retornos de linha de cache para operações atômicas por falha (algo que agora também podemos ser capazes de lidar com o novo trabalho como base).
* A taxa de falha de preenchimento zero aparece para maximizar os busses de dados internos do chip da CPU, embora ainda haja espaço para melhorias. Eu topo a 6.4M zfod / sec (cerca de 25 GBytes / s no valor de falhas de preenchimento zero) no threadripper e eu não consigo obtê-lo para ir mais alto. Note que obviamente há um pouco mais de sobrecarga de memória ram dinâmica do que a execução do código do kernel, mas ainda ...
* Taxa de exec simultânea pesada no TR (todos os 64 threads) para um binário dinâmico compartilhado aumenta de cerca de 6000 / seg para 45000 / seg. Isso é realmente importante, porque o bulk builds
* Taxa de execução simultânea pesada no TR para binários estáticos independentes agora é limitado a aproximadamente 450000 execs por segundo. Qual é um número insanamente alto.
* Taxa de falha de página com um único thread ainda é um pouco instável, mas atinge 500K-700K falhas / seg (2-3 GBytes / seg).
-
Pequena comparação de sistema usando um Ryzen 2400G (4-core / 8-thread), release vs master (isso inclui outro trabalho que entrou no master desde o último lançamento, também):
* Single threaded exec rate (shared dynamic binary) - 3180 / seg a 3650 / seg
* Taxa de exec única thread (binário estático independente) - 10307 / seg a 12443 / seg
* Taxa de exec simultânea (dinâmica compartilhada binária x 8) - 15160 / seg a 19600 / seg
* Taxa de execução simultânea binário estático independente x 8) - 60800 / seg. a 78900 / s
* Taxa de falha de enchimento zero com rosca única - 550 K zfod / s -> 604 K zfod / s
* Taxa de falha simultânea de enchimento zero (8 roscas) - 1,2 M zfod / s -> 1.7 m zfod / seg
* make -j 16 teste de buildkernel (tmpfs / usr / src, tmpfs / usr / obj):
melhoria de 4,4% no tempo total na primeira execução (melhoria de 6,2% nas execuções subseqüentes). sistema% 15,6% para 11,2% do total de segundos de CPU. Esta é uma redução de sobrecarga do kernel de 31%. Observe que o aumento do tempo de liberação é provavelmente devido à reciclagem ineficiente do cache de buffer.
DragonFlyBSD aparece na pista por um ótimo ano de 2019 com suas outras realizações recentes sendo prontas para lidar com a bagunça MDS / Zombieload , atualizações de código DRM , melhorias no HAMMER2 , lançando suporte Retpoline baseado em compilador e trabalho no FUSE , entre outras atividades de codificação.
Fonte
Até a próxima !
Nenhum comentário:
Postar um comentário