Como o agendador de kernel sabe como antecipar um processo?

Question

Tanto quanto eu entendo, o kernel não é um processo, mas sim um conjunto de manipuladores que podem ser invocados a partir do tempo de execução de outro progresso (ou pelo próprio kernel através de um temporizador ou algo similar?)

Se um programa atingir algum manipulador de exceção que exija processamento síncrono de longa execução antes que ele possa começar a ser executado novamente (por exemplo, uma falha de página que requer uma leitura de disco), como o kernel identifica que o contexto deve ser alternado? Para conseguir isso, parece que outro processo precisaria ser executado?

O kernel gera um processo que cuida disso, verificando intermitentemente os processos nesse estado? O processo que chama o manipulador síncrono de longa execução informa ao kernel que ele deve alternar os contextos até que o manipulador esteja completo (por exemplo, a leitura do disco é concluída)?

    

Answer 1

1. "O kernel não é um processo."

   Isso é pura terminologia. (A terminologia é importante.) O kernel não é um processo porque, por definição, existem processos na terra do usuário. Mas o kernel tem threads .

2. "Se um programa atingir algum manipulador de exceção que exija processamento síncrono de longa execução antes que ele possa ser executado novamente (por exemplo, um erro de página que requer uma leitura de disco)" .

   Se um processo userland executar uma instrução de máquina que faz referência a uma página de memória não mapeada, então:

   • O processador gera um trap e transita para ring 0 / supervisor mode . (Isso acontece no hardware.)

   • O manipulador de trap faz parte do kernel. Supondo que, de fato, a página de memória deve ser paginada do disco, ela colocará o processo no estado de suspensão ininterrupta (isso significa que salva o estado da CPU do processo na tabela de processos e modifica o campo de status na entrada do processo na tabela processos), localiza uma página de memória da vítima, inicia a E / S para paginar a vítima ea página na página solicitada e chama o agendador (outra parte do kernel) para alternar o contexto da área do usuário para outro processo pronto para ser executado.

   • Eventualmente, a E / S é concluída. Isso gera uma interrupção. Em resposta à interrupção, o processador chama um manipulador e transita para o modo de 0 / supervisor. (Isso acontece no hardware.)

   • O manipulador de interrupção faz parte do kernel. Ele limpa a espera pelo estado de E / S do processo que estava aguardando a página de memória e a marca pronta para ser executada. Em seguida, ele chama o agendador para alternar o contexto da área do usuário para um processo que está pronto para ser executado.

Em geral, o kernel é executado:

• Em resposta a uma interceptação ou interrupção de hardware; isso inclui interrupções temporizadas.

• Em resposta a uma chamada explícita do sistema de um processo do usuário.

Na maioria das vezes, o processador está no modo 3 do usuário / anel e executa instruções de algum processo do usuário. Ele transita para o modo ring 0 / supervisor (onde o kernel reside) quando um processo userland faz um syscall (por exemplo, porque quer fazer alguma operação de entrada / saída) ou quando o hardware gera um trap (acesso de memória inválido, divisão por zero, e assim por diante) ou quando uma requisição de interrupção é recebida do hardware (conclusão da E / S, interrupção do temporizador, movimentação do mouse, chegada do pacote na interface de rede, etc.)

Para responder a pergunta no título, "como o agendador de kernel sabe como antecipar um processo" : o kernel lida com interrupções de temporizador. Se, quando uma interrupção de timer chegar, o schduler perceberá que o processo userland atualmente em execução esgotou seu quantum Em seguida, o processo é colocado no final da fila de execução e outro processo é retomado. (Em geral, o agendador cuida para garantir que todos os processos de usuário que estão prontos para execução recebam o tempo do processador de maneira justa.)

    

Answer 2

If a program hits some exception handler that requires long-running synchronous processing before it can start running again (e.g. hits a page fault that requires a disk read), how does the kernel identify that the context should be switched? In order to achieve this, it would seem another process would need to run?

O manipulador de falhas da página do kernel chama o agendador do kernel, se a falha da página exigir uma leitura do disco.

link

filemap_fault()
wait_on_page_locked() - usually via __lock_page_or_retry()
wait_on_page_bit()
wait_on_page_bit_common()
io_schedule()
schedule()

Eu ainda não entendi o que você quer dizer com essas perguntas, mas acho que a resposta para a segunda é "não, não precisa".

Ignorando as otimizações, o kernel sempre alternará o contexto imediatamente após enfileirar a leitura. (Ou seja, isso acontece antes de filemap_fault() chamar __lock_page_or_retry() . A lógica é um pouco mais complicada, mas você pode clicar nela sem muita dificuldade).

Se não houver outros processos executáveis, o kernel mudará a CPU para sua tarefa inativa. (O kernel do Linux tem encadeamentos ociosos per-cpu. Não os veja, por exemplo, em top , ao contrário do Windows "System Idle Process").