Que estado arquitetural é salvo durante a alternância de contexto?

Question

Qual estado de arquitetura é salvo durante a alternância de contexto? Tanto quanto eu sei, o que é salvo é o seguinte

Conjunto de registros, incluindo contador de PC TLB (se não for liberado ...) o quê mais ? Memória? (contendo pilha, heap, dados) ...? É apenas deixado na memória?

    

Answer 1

Pilha de memória / pilha faz parte do espaço de endereço do processo, portanto não há necessidade de salvá-los. Sim, eles podem ser deixados lá. Cada processo teria seu próprio endereço inicial na memória física.

Os processos parecem estar usando, do ponto de vista do usuário, seu próprio intervalo de memória a partir de 0x00000000 (alguns acessos de trap de sistemas operacionais na primeira página 0x00000000-0x00000fff para capturar ponteiros nulos? - para esses, o início efetivo é 0x00001000) No entanto, a MMU remapeia a memória nos bastidores com tabelas de páginas e todas essas coisas boas. Então, é assim que a memória pode ser alocada para um processo userland, sem que o processo sequer saiba ou se importe, exceto pela quantidade total de memória (o limite superior) que ele pode acessar.

O ponteiro da pilha, no entanto, precisa ser salvo, mas isso faz parte dos registros.

    

Answer 2

Depende do processador e, por inferência, do que é necessário para representar o estado da tarefa. Também depende, até certo ponto, do sistema operacional.

No antigo Unix original (pré-memória virtual), os registradores seriam salvos em um local fixo na memória, então toda a memória do usuário gravada no disco e uma nova imagem de memória do usuário seriam lidas. realizado simplesmente pulando a etapa "read it in".) Isso foi muito rapidamente suplantado por um esquema de troca virtual quando as CPUs com TLBs se tornaram disponíveis ("Berkley Unix").

Em uma arquitetura de pilha no estilo Burroughs, tudo o que precisa ser trocado (em teoria) é o ponteiro da pilha e o ID da tarefa. Endereçamento de memória (no original) é via "capacidades" e "segmentos", vs usando um TLB.

Arquiteturas de registro mais antigas com memória virtual baseada em TLB requeriam que as TLBs (e algumas vezes cache) pelo menos fossem invalidadas em swap, além de trocar os registradores de programa (incluindo IAR, código de condição, etc). Novas arquiteturas baseadas em TLB aperfeiçoam esse problema de várias maneiras, evitando o flushing, de modo que um retorno bastante rápido não precise recarregar tudo. (Por esse motivo, no sistema multiprocessador, as tarefas geralmente recebem uma "afinidade" de um determinado processador, para minimizar a quantidade de recarga de TLB / cache.)