Qual é a diferença entre cache físico e virtual?


11

Estou tendo problemas para entender o que é realmente o cache virtual. Eu entendo memória virtual.

Se a CPU quiser acessar a memória, pelo que entendi, ela envia um endereço virtual para a MMU que, usando tabelas de páginas, descobre o endereço da memória física.

Agora, além disso, a CPU envia um endereço diferente (apenas o final do endereço virtual), que consiste em um conjunto no. uma tag e um deslocamento, para o cache, que funciona se ele reside no cache.

Como o cache virtual difere disso?

insira a descrição da imagem aqui


2
Você quer dizer um cache virtualmente endereçado (virtualmente indexado / virtualmente marcado)?
22316 Paul A. Clayton

Basicamente, quero dizer qual é a diferença entre um endereço de cache virtual e um endereço de cache físico? (I foi a impressão de um endereço físico de cache está na forma (setno (índice), (linha não) etiqueta, e offset)...
OneTwo

Veja meu documento de pesquisa de 2017 sobre TLB , onde discuto e comparo quatro tipos de opções de endereçamento de cache (PIPT, VIPT, VIVT, PIVT) com figuras. Isso responderá sua pergunta. O cache VIVT é geralmente chamado de cache virtual.
user984260

Respostas:


20

Existem quatro maneiras de endereçar um cache, dependendo se os bits de endereço virtual ou físico são usados ​​para indexação e / ou marcação.

Como a indexação do cache é a mais crítica em termos de tempo (como todas as maneiras em um conjunto podem ser lidas em paralelo e a maneira apropriada selecionada com base em uma comparação de tags), os caches são tipicamente indexados com o endereço virtual, permitindo que a indexação comece antes do endereço a tradução está concluída. No entanto, se apenas os bits dentro do deslocamento da página forem usados ​​para indexação (por exemplo, cada caminho não é maior que o tamanho da página e o módulo simples do tamanho do caminho para a indexação 1 ), essa indexação está realmente usando o endereço físico. Não é incomum que a associatividade L1 seja aumentada principalmente para permitir que um cache maior seja indexado pelo endereço físico.

Embora a indexação com base no endereço físico seja possível com maneiras maiores que o tamanho da página (por exemplo, prevendo os bits mais significativos ou um mecanismo de conversão rápida que forneça esses bits usando o atraso da indexação com os bits de endereço físico conhecidos para ocultar a latência da tradução), não é comumente feito.

O uso de endereços virtuais para marcação permite determinar uma ocorrência de cache antes da tradução. As permissões ainda precisam ser verificadas antes que o acesso possa ser confirmado, mas para cargas, os dados podem ser encaminhados para as unidades de execução e computação usando os dados iniciados e, para armazenamentos, os dados podem ser enviados para um buffer para permitir o comprometimento tardio do estado. Uma exceção de permissão liberaria o pipeline, portanto, isso não adiciona complexidade ao design.

(Os vhints usados ​​pelo cache de dados do Pentium 4 forneceram essa vantagem de latência usando um subconjunto dos bits de endereço virtual que estão disponíveis cedo para selecionar especulativamente o caminho.)

(Nos dias de MMUs externas opcionais, as etiquetas de endereço virtual poderiam ser particularmente atraentes ao empurrar a tradução quase inteiramente para fora do design do cache.)

Embora os caches virtualmente indexados e marcados possam ter vantagens significativas de latência, eles também introduzem o potencial de aliasing onde o mesmo endereço virtual mapeia para endereços físicos diferentes (homônimos) ou o mesmo endereço físico mapeia para endereços virtuais diferentes (sinônimos). A indexação e marcação com endereços físicos evita o alias.

O problema de homônimo é resolvido com relativa facilidade usando identificadores de espaço de endereço (ASIDs). (A limpeza do cache ao alterar os espaços de endereço também não garante homônimos, mas isso é relativamente caro. Seria necessária pelo menos uma descarga parcial quando um ASID fosse reutilizado para um espaço de endereço diferente, mas um ASID de 8 bits pode evitar descargas na maioria dos endereços. mudanças de espaço.) Normalmente, os ASIDs seriam gerenciados pelo sistema operacional, mas alguns sistemas forneciam verificações de hardware para reutilização do ASID com base no endereço base da tabela de páginas.

O problema do sinônimo é mais difícil de resolver. Em uma falta de cache, os endereços físicos de qualquer alias possível devem ser verificados para determinar se um alias está presente no cache. Se o aliasing for evitado na indexação - indexando com o endereço físico ou pelo sistema operacional, garantindo que os aliases tenham os mesmos bits no índice (coloração da página) -, somente o conjunto precisa ser analisado. Ao realocar qualquer sinônimo detectado para o conjunto indicado pelo endereço virtual usado mais recentemente, o alias é evitado no futuro (até que um mapeamento diferente do mesmo endereço físico ocorra).

Em um cache mapeado virtualmente com mapeamento direto sem alias de índice, é possível uma simplificação adicional. Como o sinônimo em potencial entra em conflito com a solicitação e é despejado, qualquer write-back necessário de uma linha suja pode ser feito antes que a falha do cache seja tratada (para que um sinônimo esteja na memória ou em um cache de nível superior endereçado fisicamente) ou endereçado fisicamente o buffer de write-back pode ser analisado antes da instalação da linha de cache buscada na memória (ou cache de nível superior). Um alias não modificado não precisa ser verificado, pois o conteúdo da memória será o mesmo do cache, apenas manipulando erros desnecessariamente. Isso evita a necessidade de tags físicas adicionais para todo o cache e permite que a tradução seja relativamente lenta.

Se não houver uma garantia garantida de alias no índice, mesmo um cache marcado fisicamente precisará verificar os outros conjuntos que podem conter alias. (Para um bit de índice não físico, uma segunda análise do cache no conjunto alternativo único pode ser aceitável. Isso seria semelhante à pseudo-associatividade.)

Para um cache virtualmente marcado, um conjunto extra de tags de endereço físico pode ser fornecido. Essas tags seriam acessadas apenas em caso de falha e podem ser usadas para coerência de cache de E / S e multiprocessador. (Como os erros e solicitações de coerência são relativamente raros, esse compartilhamento não é tipicamente problemático.)

O Athlon da AMD, que usava marcação física com indexação virtual, fornecia um conjunto separado de tags para testes de coerência e detecção de alias. Como três bits de endereço somente virtual são usados ​​para indexação, sete conjuntos alternativos precisavam ser sondados para possíveis aliases em caso de falha. Como isso pode ser feito enquanto se aguarda uma resposta do cache L2, isso não adiciona latência e o conjunto extra de tags também pode ser usado para solicitações de coerência mais frequentes devido à exclusividade do cache L2.

Para um grande cache L1 praticamente indexado, uma alternativa para investigar muitos conjuntos adicionais seria fornecer um cache de tradução físico para virtual. Em caso de falha (ou investigação de coerência), o endereço físico seria traduzido para o endereço virtual que pode ser usado no cache. Como seria impraticável fornecer uma entrada no cache de tradução para cada linha de cache, seria necessário um meio para invalidar as linhas de cache quando uma tradução fosse despejada.

Se for garantido que o alias (pelo menos de endereços graváveis) não ocorra, por exemplo, em um sistema operacional típico de espaço de endereço único, a única desvantagem de um cache virtualmente endereçado é a sobrecarga de tag extra do fato de que endereços virtuais nesses sistemas são maior que endereços físicos. O hardware projetado para um SO de espaço de endereço único poderia usar um buffer de permissão lateral em vez de um buffer de tradução lateral, atrasando a conversão até uma falha no cache de último nível.


1 A associatividade distorcida indexa diferentes maneiras do cache com diferentes hashes com base em mais bits do que o necessário para a indexação de módulos do mesmo tamanho. Isso é útil para reduzir erros de conflito. Isso pode introduzir problemas de aliasing que não estariam presentes em um cache indexado por módulo do mesmo tamanho e associatividade.


"Não é incomum que a associatividade L1 seja aumentada principalmente para permitir que um cache maior seja indexado pelo endereço físico". Você quis dizer virtual lá? Por exemplo, para manter o número de bits de seleção de conjuntos baixo o suficiente para permanecer inteiramente dentro de uma página (e, portanto, não precisar de tradução), o cache pode continuar sendo indexado virtual fisicamente com tags físicas para menor latência. Ou você estava chamando esses bits abaixo do deslocamento da página de "endereços físicos"?
Peter Cordes

1
@ PeterCordes Eu estava chamando o deslocamento dentro de uma parte da página do endereço físico (para esses bits virtuais === físicos). Se alguém enfatiza a latência, pode tender a chamar isso de virtualmente indexado; se alguém enfatiza a falta de problemas de alias, pode tender a chamá-lo de indexado fisicamente.
Paul A. Clayton

Obrigado. Você foi notificado quando eu o marquei em outro segmento em stackoverflow.com/questions/33974193/… ? Eu estava esperando uma resposta especializada sobre se os caches L2 / L3 são tipicamente indexados fisicamente, para que possam ser grandes sem precisar de uma grande associação. (Presumo que sim, porque eles não são verificados até que L1 perca, o que acontece após o TLB, portanto o endereço físico está disponível). Existem outras coisas intrigantes que surgiram nessa discussão também.
Peter Cordes
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.