O que acontece com o conteúdo do cache em uma opção de contexto?


50

Em um processador multicore, o que acontece com o conteúdo do cache de um núcleo (por exemplo, L1) quando ocorre uma alternância de contexto nesse cache?

O comportamento depende da arquitetura ou é um comportamento geral seguido por todos os fabricantes de chips?

Respostas:


42

Isso depende do processador (não apenas da série de processadores, pode variar de modelo para modelo) e dos sistemas operacionais, mas existem princípios gerais. Se um processador é multicore não tem impacto direto nesse aspecto; o mesmo processo pode estar sendo executado em vários núcleos simultaneamente (se for multithread) e a memória pode ser compartilhada entre os processos; portanto, a sincronização do cache é inevitável, independentemente do que acontece em uma alternância de contexto.

Quando um processador procura um local de memória no cache, se houver um MMU , ele pode usar o endereço físico ou o virtual desse local (às vezes até uma combinação de ambos, mas isso não é relevante aqui).

Com endereços físicos, não importa qual processo está acessando o endereço, o conteúdo pode ser compartilhado. Portanto, não há necessidade de invalidar o conteúdo do cache durante uma alternância de contexto. Se os dois processos mapearem a mesma página física com atributos diferentes, isso será tratado pela MMU (atuando como uma MPU (unidade de proteção de memória)). A desvantagem de um cache endereçado fisicamente é que a MMU precisa ficar entre o processador e o cache, para que a pesquisa seja lenta. Caches L1 quase nunca são endereços fisicamente; caches de nível superior podem ser.

O mesmo endereço virtual pode indicar diferentes locais de memória em diferentes processos. Portanto, com um cache praticamente endereçado, o processador e o sistema operacional devem cooperar para garantir que um processo encontre a memória correta. Existem várias técnicas comuns. O código de alternância de contexto fornecido pelo sistema operacional pode invalidar todo o cache; isso é correto, mas muito caro. Algumas arquiteturas de CPU têm espaço em sua linha de cache para um ASID (identificador de espaço de endereço), a versão de hardware de uma identificação de processo, também usada pela MMU. Isso efetivamente separa as entradas de cache de diferentes processos e significa que dois processos que mapeiam a mesma página terão exibições incoerentes da mesma página física (geralmente há um valor ASID especial que indica uma página compartilhada, mas eles precisam ser liberados se não estiverem mapeados para o mesmo endereço em todos os processos em que estão mapeados). Se o sistema operacional tomar cuidado para que processos diferentes usem espaços de endereço sem sobreposição (o que anula parte do objetivo de usar memória virtual, mas pode ser feito algumas vezes), as linhas de cache permanecem válidas.

A maioria dos processadores que possuem uma MMU também possui um TLB . O TLB é um cache de mapeamentos de endereços virtuais para endereços físicos. O TLB é consultado antes de pesquisas em caches endereçados fisicamente, para determinar o endereço físico rapidamente quando possível; o processador pode iniciar a pesquisa de cache antes que a pesquisa TLB seja concluída, pois muitas vezes as linhas de cache candidatas podem ser identificadas a partir dos bits do meio do endereço, entre os bits que determinam o deslocamento em uma linha de cache e os bits que determinam a página. Caches virtualmente endereçados ignoram o TLB se houver um acerto no cache, embora o processador possa iniciar a pesquisa do TLB enquanto estiver consultando o cache, em caso de falha.

O TLB em si deve ser gerenciado durante uma alternância de contexto. Se as entradas TLB contiverem um ASID, elas poderão permanecer no local; o sistema operacional só precisa liberar as entradas TLB se seu ASID mudou de significado (por exemplo, porque um processo foi encerrado). Se as entradas TLB forem globais, elas deverão ser invalidadas ao alternar para um contexto diferente.


2
Muito informativo. Se você pudesse adicionar alguns exemplos de como isso é feito em arquiteturas reais, seria ainda melhor.
31814 JohnTortugo

2
@JohnTortugo O que eu escrevi corresponde bastante ao que você pode fazer no ARMv7 (por exemplo, a CPU do seu smartphone) (a única arquitetura em que eu já escrevi o código de manipulação da MMU). Espero que outras plataformas, como x86, sejam bastante semelhantes, mas não consegui escrever sobre elas. Se você está procurando informações concretas sobre uma plataforma real, a Ciência da Computação não é o site certo, você pode perguntar sobre Stack Overflow ou Electrical Engineering ou Embeddedd (proposto) .
Gilles 'SO- stop be evil'

10

O cache normalmente não tem uma opção de contexto. Somente a sequência de endereços de memória acessados ​​determina quais linhas de cache são substituídas.

A política de substituição geralmente é uma heurística dependente do fabricante e da microarquitetura específica. O problema é que a heurística não pode prever o futuro, qual endereço e, portanto, a linha de cache será acessada a seguir.

A heurística pode ser simples como LRU (usada menos recentemente). Porém, com as CPUs modernas, as heurísticas são mais complexas.

Dê uma olhada no Manual do desenvolvedor de software das arquiteturas Intel® 64 e IA-32, Volume 3. O Capítulo 11 explica o cache da memória e os mecanismos de controle de cache. A AMD possui isso no Capítulo 7 do Manual do programador de arquitetura AMD64, Volume 2: Programação do sistema . Para CPUs baseadas em ARM, parece que os PDFs estão disponíveis apenas para clientes registrados.


Você pode dar uma referência para o primeiro parágrafo? Ou os documentos vinculados se referem a esse problema?
Raphael

O comportamento depende muito se o cache é fisicamente ou virtualmente tratado. A política de substituição não é relevante aqui. Para o ARM, há informações nos manuais técnicos do processador, que são públicas, por exemplo, L1 no Cortex-A9 (o que você obtém nos telefones celulares de última geração), embora possa ser difícil de entender sem o manual de referência da arquitetura não pública .
Gilles 'SO- stop be evil'

11
@ Rafael Escrevi “normalmente” porque, com os processadores que encontrei, o cache em si não possui nenhum conhecimento sobre threads, processos, contextos etc. Ele apenas reage aos acessos à memória. Se o cache de dados estiver liberado e o cache de instruções invalidado em uma alternância de contexto, é o SO que aciona essa ação, não o cache. Se você instalar um sistema operacional diferente, esse comportamento poderá mudar.
uli

@Gilles Pela primeira vez, tentei dar uma resposta curta e decidi não escrever sobre memória virtual, porque isso envolve imediatamente o sistema operacional. E há a escala de tempo a considerar também. "Nada muda" pode ser uma resposta para o tempo entre a alternância de contexto e o próximo acesso à memória, pois o conteúdo do cache pode ser invalidado, mas não alterado.
uli
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.