Na falha da página, como o Unix determina se o endereço com falha está no espaço de troca?

0

Quando ocorre uma falha de página para um endereço virtual para qualquer processo, como o sistema operacional linux / unix determina se a página (desse endereço virtual) foi trocada anteriormente na memória e trocada para o disco (ou seja, essa página está atualmente presente no espaço de troca) ou essa página nunca foi carregada na memória antes (ou seja, essa página não está presente no espaço de troca)?

    
por CodeWithPride 02.09.2015 / 06:45

2 respostas

1

O manipulador de falhas de página de baixo nível no sistema operacional (listado na tabela de armadilhas da CPU) obtém o endereço de falha da CPU e usa esse endereço de falha para verificar as entradas na tabela de descrição de espaço de endereço do processo. Esta tabela contém uma lista de descritores de segmento, cada um contendo um endereço base e um tamanho. Se o endereço não estiver nessa lista. o sistema operacional envia um SIGSEGV (segmentati violati).

Se o endereço puder ser encontrado, a entrada da tabela de segmento que é responsável pelo intervalo de endereços que inclui o endereço de falha também contém um ponteiro para as funções do driver do driver de segmento relacionado.

Um driver de segmento gerencia o VMEM para ações de memória em segundo plano. Se o endereço estiver relacionado ao espaço de troca, o nome do driver responsável será anon .

Existem muitos drivers de segmento, por ex. um driver de segmento para cada sistema de arquivos, pois basicamente todas as operações de E / S de dados do sistema de arquivos são tratadas via mmap ().

    
por 02.09.2015 / 11:54
3

Primeiro, precisamos ver o que acontece no nível do hardware. Uma falha de página acontece quando a MMU tenta excluir a referência de um endereço virtual e encontra um descritor inválido para esse endereço. Quando isso acontece, o processador executa um trap: ele alterna para o modo kernel, pula para um endereço predefinido (o vetor trap) e preenche alguns registradores para indicar que uma falha de página aconteceu, e informações suficientes para permitir que o kernel determine o que endereço solicitado foi, quais instruções causaram a falha e em qual tarefa. Eu estou dando a idéia geral aqui, os detalhes concretos variam entre arquiteturas de processador.

O código do manipulador de trap, que faz parte do kernel, examina registros e memória para determinar a natureza da falha (o mesmo manipulador pode ser chamado para diferentes tipos de exceções), o endereço solicitado e qual processo que estava ativo anteriormente . Em seguida, ele consulta algumas estruturas de dados que indicam o que deve ser mapeado nesse processo nesse endereço. Aqui, novamente, a natureza da estrutura de dados varia entre as arquiteturas do processador e também entre as variantes do Unix. Algumas arquiteturas de processador têm bits suficientes em um descritor inválido que não são interpretados pela MMU para armazenar um número de setor de swap, caso em que o kernel não precisa consultar nenhuma outra estrutura de dados. Se esse não for o caso, o kernel consultará uma estrutura de dados anexada ao processo e descreverá seus mapeamentos de memória.

O mesmo mecanismo também pode determinar várias outras coisas, como:

  • A página precisa ser carregada de um arquivo, para arquivos mapeados pela memória.
  • A memória é mapeada, mas a operação não foi autorizada, por ex. Foi uma tentativa de escrever para a memória somente leitura. Neste caso, o kernel organiza a troca de controle para o sinal SIGSEGV do processo, se houver um, e caso contrário, o processo é finalizado.
  • Foi feita uma tentativa de gravar em uma página marcada como somente leitura para a CPU, mas marcada como copy-on-write. Nesse caso, o kernel faz uma cópia da página.

Se o kernel conseguir obter uma página na RAM que tenha o conteúdo que o processo espera, atualizará o mapa de memória do processo para refletir isso. Então o kernel transfere o controle de volta ao processo, como em um switch de contexto; mas em vez de retornar o controle logo após a instrução de que o processo foi executado, ele retorna o controle imediatamente antes desta instrução, de modo que a instrução com falha seja executada novamente, desta vez com sucesso.

    
por 03.09.2015 / 04:07