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

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. )?

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."

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.