Quando fazer ou não o INVLPG, MOV para CR3 para minimizar a descarga do TLB
Eu sou um hobby de sistema operacional, e meu kernel roda em 80486+ e já suporta memória virtual.
A partir de 80386, a família de processadores x86 da Intel e vários clones dela suportam memória virtual com paginação. É sabido que quando oPG mordeuCR0 está definido, o processador usa a conversão de endereço virtual. Então oCR3 registre pontos no diretório de página de nível superior, que é a raiz para 2-4 níveis de estruturas de tabela de páginas que mapeiam os endereços virtuais para endereços físicos.
O processador não consulta essas tabelas para cada endereço virtual gerado, colocando-as em cache em uma estrutura chamadaTradução Lookaside Bufferou TLB. No entanto, quando são feitas alterações nas tabelas de páginas, o TLB precisa ser liberado. Nos processadores 80386, essa liberação seria feita recarregando (MOV) CR3 com o endereço do diretório da página de nível superior ou uma opção de tarefa. Isso supostamente libera incondicionalmente todas as entradas TLB. Pelo que entendi, seria perfeitamente válido para um sistema de memória virtualsempre recarregue CR3 depois dequalquer mudança.
Isso é um desperdício, já que o TLB lançaria entradas completamente boas, portanto, nos processadores 80486, oINVLPG instrução foi introduzida.INVLPG invalidará a entrada TLB correspondente ao endereço do operando de origem.
No entanto, a partir do Pentium Pro, também temos páginas globais que não estão alinhadas com as mudanças paraCR3 ou troca de tarefas; eo AMD x86-64 ISA afirma que algumas estruturas de tabela de página de nível superior podem ser armazenadas em cache e não invalidadas porINVLPG. Para obter uma imagem coerente do que é necessário e do que não é necessário em cada ISA, seria realmente necessário fazer o download de uma folha de dados de 1000 páginas para várias ISAs lançadas desde os anos 80 para ler algumas páginas e, mesmo assim, os documentos parecem ser particularmente vago quanto à invalidação do TLB e o que acontece se o TLB não for adequadamente invalidado.
Pela simplicidade, pode-se supor queestamos falando de um sistema uniprocessador. Além disso, pode-se supor quenenhuma troca de tarefas é necessária após alterar as estruturas da página. (portantoINVLPG é sempre supostamente pelo menos tão boa escolha quanto recarregar oCR3 registo).
A suposição básica é que seria necessário recarregarCR3 após cada alteração nas tabelas e diretórios de páginas, e esse sistema estaria correto. No entanto, se alguém quiser evitar a descarga desnecessária do TLB, precisará de respostas para as 2 perguntas:
Providenciou queINVLPG é suportado no ISA, depois de que tipo de alterações alguém pode usá-lo com segurança em vez de recarregar oCR3? Por exemplo. "Se desmarcar um quadro de página (defina a entrada da tabela correspondente como não presente), sempre será possível usarINVLPG"?
Que tipo de alterações é possível fazer nas tabelas e diretórios sem tocar emCR3 ou executandoINVLPG? Por exemplo. "Se uma página não estiver mapeada (não presente), pode-se escrever um PTE comPresent=1 por isso sem liberar o TLB em tudo "?
Mesmo depois de ler uma grande quantidade de documentos ISA e tudo relacionado aINVLPG aqui no Stack Overflow, não tenho pessoalmente certeza dos exemplos que apresentei lá. De fato, umpostagem notável afirmou imediatamente: "Não sei exatamente quando você deve usá-lo e quando não deve." Assim, quaisquer exemplos certos e corretos, de preferência documentados, e para IA32 ou x86-64, que você pode dar, são apreciados.