Os Relaxed TLB Flushes estão sendo trabalhados no Linux como uma outra otimização de desempenhos

 

Confira !!

Nadav Amit, que anteriormente liderou o trabalho na redução de flushes de TLB desnecessários, flushes de TLB simultâneos e outras otimizações de baixo nível ao longo dos anos. O trabalho mais recente está agora em liberações de TLB "relaxadas" como outra melhoria de desempenho de baixo nível.

Nadav Amit, da VMware, assumiu o trabalho em liberações de TLB "relaxadas" para quando as permissões são adicionadas como trabalho de acompanhamento ao seu trabalho anterior para evitar liberações de TLB desnecessárias. Ele explica:

Este conjunto de patches permite que o userfaultfd mapeie as páginas como graváveis ​​diretamente no write-(un)protect ioctl, enquanto aborda os comportamentos indesejados que ocorrem quando se usa userfaultfd write-unprotect ou mprotect para adicionar permissões. Ele também faz algumas limpezas e micro-otimizações ao longo do caminho.

A principal mudança que é feita no conjunto de patches - específico para x86, no momento - é a introdução de liberações de TLB "relaxadas" quando as permissões são adicionadas. Após uma descarga de TLB "relaxada", a geração de TLB do mm é avançada e a TLB local é liberada, mas não ocorre nenhuma derrubada de TLB. Se ocorrer uma falha de página espúria e a geração local do TLB estiver fora de sincronia com a geração mm, uma liberação completa de TLB será executada no núcleo com falha para evitar mais falhas de página espúrias.

Até certo ponto, os "fluxos relaxados" são semelhantes às mudanças que foram propostas há algum tempo para mapeamentos de kernel. No entanto, ele não tem interações complicadas com manipuladores NMI.

A liberação de TLB relaxada foi resumida em sua mensagem de patch:

Introduzir o conceito de flushes TLB estritos e relaxados. Liberações de TLB relaxadas são liberações de TLB que podem ser ignoradas, mas podem levar a um desempenho degradado. Depende do código do arco (nos próximos patches) lidar corretamente com os flushes relaxados. Um desses comportamentos é liberar o TLB local ansiosamente e os TLBs remotos preguiçosamente.

Os experimentos de desempenho parecem bastante positivos com até 44% de economia medida em ciclos de mprotect(PROT_READ|PROT_WRITE) ou cerca de 6% menos ciclos de CPU com apenas mprotect(PROT_READ).

Mais detalhes nesta série de patches LKML .

Fonte

Até a próxima !!