As caminhadas pelas tabelas da página são armazenadas em cache?


12

Em um microprocessador com gerenciamento de TLB de hardware (por exemplo, um Intel x86-64), se ocorrer uma falha no TLB e o processador estiver percorrendo a tabela de páginas, são esses acessos de memória (sem chip) passando pela hierarquia de cache (L1, L2, etc. )?


Nada a ver com design eletrônico. A pergunta será encerrada.
Leon Heller

8
Está perguntando como funciona um determinado chip, então acho que está no tópico.
Olin Lathrop 28/10

5
@OlinLathrop: Eu concordo: acho que os detalhes de baixo nível de um circuito integrado estão no tópico.
Davidcary

Eu tenho que concordar, se nada mais, depurar a função de nossos processadores é um passo importante para obter um sistema decentemente determinístico projetado. Isso está se aproximando de um de nossos limites, mas parece fortemente interno.
22811 Kortuk

Respostas:


8

Sim, até onde eu sei, nos processadores Intel x86-64, quando ocorre uma falha no TLB e o processador está andando na tabela de páginas, esses acessos à memória sem chip passam pela hierarquia do cache.

Ainda estou um pouco confuso com alguns detalhes, e espero que outra resposta os preencha - não há um manual da Intel ou AMD que descreva a página em detalhes excruciantes? Meu entendimento é que:

  • O endereço virtual em algum registro de endereço é entregue primeiro a um TLB rápido para ser convertido em endereço físico - o endereço no PC é entregue ao L1 ITLB, o endereço em qualquer outro registro é entregue ao L1 DTLB .
  • Se essa primeira pesquisa falhar, há outro nível de TLB maior e mais lento que é tentado. (Este TL2 L2 é dividido em um ITLB e um DTLB também, ou é um cache TLB unificado? Existem outros níveis de TLB - L3? L4?)
  • Se a pesquisa TLB falhar completamente e o walker x86 e x86-64 VHPT estiver desativado, a CPU sinalizará uma falha de falta TLB, que é interceptada pelo kernel do sistema operacional. Meu entendimento é que praticamente todas as CPUs não x86 fazem a mesma coisa - lidam com falhas TLB inteiramente em software. Se ativado, os processadores x86 e x86-64 têm o caminhante de tabela VHPT assistido por hardware que lida com as próximas etapas. (Os chips x86 e x86-64 têm um bit que desativa completamente o VHPT ou existem muitos bits que podem ativar o VHPT para alguns intervalos de endereços e desativar o VHPT para outros intervalos de endereços? Onde estão esses bits?)
  • se a pesquisa TLB falhar completamente, o endereço virtual original (provavelmente no modo de usuário) V1 será convertido em V2, o endereço virtual da entrada da tabela de páginas PTE que contém o número da página física da V1.
  • Como V2 é novamente um endereço virtual, a CPU passa pela tradução normal de endereço virtual para físico, exceto que ignora L1 e vai direto para L2.
  • O hardware procura o endereço virtual V2 no TLB em paralelo com a busca desse PTE no cache L2 (praticamente indexado).
  • Como V2 não é o endereço de uma instrução, ela não passa pelo cache de instruções L1; e como V2 não é o endereço dos dados normais do usuário, ele não passa pelo cache de dados L1. V2 é alimentado inicialmente no cache unificado L2 (uma instrução unificada + dados + cache PTE). Veja o "exemplo de hierarquia de cache" .
  • Se o cache L2 (ou L3 ou qualquer outro cache virtualmente indexado) contiver o PTE, o VHPT buscará o PTE na memória cache e instalará o PTE para V1 no TLB e o endereço físico nesse PTE será usado para converter o PTE. endereço virtual original V1 no endereço físico da RAM, buscando esses dados ou instruções inteiramente em hardware sem qualquer assistência do sistema operacional.
  • Se todos os níveis de cache virtualmente indexado falharem, mas essa segunda pesquisa TLB for bem-sucedida para a V2, o VHPT buscará o PTE do cache fisicamente indexado ou da memória principal, instalará o PTE para V1 no TLB e o endereço físico nesse O PTE é usado para converter o endereço virtual original V1 no endereço físico da RAM, buscando esses dados ou instruções inteiramente no hardware sem qualquer assistência do sistema operacional.
  • Se essa segunda pesquisa TLB falhar, o hardware VHPT walker desiste de uma Falha na tradução do VHPT.
  • Quando ocorre uma Falha na tradução do VHPT, a CPU intercepta o sistema operacional. O sistema operacional precisa descobrir o que deu errado e consertar as coisas:
  • (a) talvez a página que contém a V2 esteja atualmente trocada para o disco, para que o sistema operacional a leia na RAM e reinicie a instrução com falha, ou
  • (b) talvez um programa com bugs esteja tentando ler, gravar ou executar algum local inválido e o sistema operacional finalize o processo, ou
  • (c) uma variedade de outros truques que os gravadores do SO fazem para usar esse mecanismo para interceptar vários tipos de acesso - carregue a página que contém a V1 que pode ser trocada para o disco; várias armadilhas usadas para depurar novos programas; simular "W ^ X" em CPUs que não suportam diretamente; oferecer suporte à cópia na gravação; etc.

O diagrama da página 2 de Thomas W. Barr, Alan L. Cox e Scott Rixner. "Cache de tradução: ignore, não ande (a tabela de páginas)" que desenha uma linha entre "Entradas armazenadas pelo cache MMU" e "entradas armazenadas pelo cache de dados L2". (Este pode ser um documento útil para quem cria novas CPUs , que é totalmente tópico sobre "Design de eletrônicos").

Stephane Eranian e David Mosberger. "Memória virtual no kernel IA-64 Linux" e Ulrich Drepper. "O que todo programador deve saber sobre memória" (este pode ser um documento útil para quem escreve sistemas operacionais que lidam com a tabela de páginas IA-64, que é um pouco fora de tópico para o ED - talvez Stack Overflow com o " sistema " ou " osdev " ou o wiki do OSDev.org seria um lugar melhor para esse tópico).

Tabela A-10 na página 533 da Intel. "Manual do desenvolvedor de software das arquiteturas Intel® 64 e IA-32" "PAGE_WALKS.CYCLES ... pode sugerir se a maioria das percursos de página é satisfeita pelos caches ou causa um erro de cache L2."


Adoro a resposta, mas provavelmente sou uma das muitas que não têm a experiência necessária para se sentir à vontade para dar o que provavelmente é um voto merecido. Como outros especialistas verificam, darei o representante que você já ganhou.
Kortuk

Não acredito que isso esteja correto. O marcador 1 + 2 sobre a pesquisa TLB está correto em AFAICT, mas 3 não está. As tabelas da página em x86 (ou x86-64) não são tratadas no software (uma exceção se aplica, veja mais tarde), mas no hardware. Ou seja, quando a CPU determina que não pode resolver o endereço usando TLB, ela mesma percorre as tabelas de páginas começando na tabela apontada pelo registro CR3. Somente se esta resolução não for bem-sucedida, ele chamará o manipulador de falhas de página da CPU. A exceção são as extensões de virtualização em que, em certos modos, o hipervisor resolve uma falha de página que ocorre no convidado.
Morty 23/09

Eu não acho que o x86 tenha uma maneira de fazer atualizações de TLB de software. Os ISAs que permitem o tratamento com TLB simples têm instruções especiais para o SW modificar as entradas TLB, mas não acho que o x86 tenha isso além de invlpginvalidar qualquer cache TLB para um determinado endereço virtual. Se a caminhada de página do HW não encontrar uma entrada para esse endereço virtual ou as permissões da entrada não permitirem o acesso, você receberá uma #PFexceção. O sistema operacional lida com isso atualizando a tabela de páginas (possivelmente após a paginação dos dados do disco ou fazendo a cópia na gravação) e, em seguida, continuando para que o carregamento / armazenamento defeituoso seja executado novamente e a paginação HW seja bem-sucedida.
Peter Cordes


4

Costumo concordar que isso pertence a uma arquitetura de computadores stackexchange, não a um stackexchange de eletrônica, mas como está aqui:

@davidcary está correto.

Alguma história:

Os passeios pela tabela de páginas Intel x86 NÃO foram armazenados em cache até o P5, também conhecido como Pentium. Mais precisamente, os acessos à memória de passeio da tabela de páginas não foram armazenados em cache, ignoraram o cache. Como a maioria das máquinas até então era de gravação, elas receberam valores consistentes com o cache. Mas eles não bisbilhotaram os caches.

P6, também conhecido como Pentium Pro e AFAIK, todos os passeios subsequentes da tabela de páginas dos processadores tiveram permissão para acessar o cache e usar um valor extraído do cache. Assim, eles trabalharam com caches de write-back. (Você pode, é claro, colocar as tabelas de páginas em memória incachável, definida, por exemplo, pelos MTRRs. Mas isso é uma grande perda de desempenho, embora possa ser útil para depurar sistemas operacionais.)

A propósito, esse "acesso à memória de passeio da tabela de páginas pode acessar os caches de dados" é separado de "as entradas da tabela de páginas podem ser armazenadas (armazenadas em cache) em um Buffer de TLS de tradução da TLB". Em algumas máquinas, o TLB é chamado de "cache de tradução".

Outro problema relacionado é que os nós internos das tabelas de páginas podem ser armazenados em cache em ainda mais estruturas de dados do tipo TLB, por exemplo, o cache do PDE.

Uma diferença importante: o cache de dados é coerente e espionado. Mas os caches TLB e PDE não são espionados, ou seja, não são coerentes. A linha inferior é que, como as tabelas de páginas podem ser armazenadas em cache em TLBs e PDE não coerentes, o software deve liberar explicitamente as entradas individuais ou os grupos em massa (como todo o TLB), quando as entradas da tabela de páginas podem ter sido tão comuns. em cache são alterados. Pelo menos quando alterado de maneira "perigosa", passando de RW-> R-> I ou alterando endereços.

Eu acho que é justo dizer que toda vez que um novo tipo de cache não-coerente do tipo TLB é adicionado, algum sistema operacional é interrompido, porque havia suposições implícitas de que isso não estava sendo feito.


Um novo comp. arco. A proposta começou apenas "há 3 meses". Acho que houve um anterior que nunca saiu da área51 (não há seguidores suficientes?).
Paul A. Clayton
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.