Respostas:
Em um kernel preemptivo, um processo em execução no modo kernel pode ser substituído por outro processo enquanto estiver no meio de uma função do kernel.
Isso se aplica apenas a processos em execução no modo kernel, uma CPU executando processos no modo usuário é considerada "inativa". Se um processo no modo de usuário quiser solicitar um serviço do kernel, ele precisará emitir uma exceção que o kernel possa manipular.
Como um exemplo:
Processo Aexecuta um manipulador de exceção, Processo Bé despertado por uma solicitação de IRQ, o kernel substitui o processo Apor B(uma troca forçada de processo). O processo Aé deixado inacabado. O planejador decide depois se o processo Aobtém tempo de CPU ou não.
Em um kernel não-preventivo, o processo Ateria usado todo o tempo do processador até que ele fosse concluído ou voluntariamente decidisse permitir que outros processos o interrompessem (uma troca de processo planejada).
Os sistemas operacionais atuais de Linux geralmente não incluem um kernel totalmente preventivo; ainda existem funções críticas que precisam ser executadas sem interrupção. Então eu acho que você poderia chamar isso de "núcleo preventivo seletivo".
Além disso, existem abordagens para tornar o kernel do Linux (quase) totalmente preventivo.
a preempção é -> A capacidade do sistema operacional de antecipar ou interromper uma tarefa agendada no momento em favor de uma tarefa de maior prioridade. O planejamento pode ser um, mas não limitado a, processo ou planejamento de E / S, etc.
No Linux, os programas de espaço do usuário sempre foram preemptivos: o kernel interrompe os programas de espaço do usuário para alternar para outros threads, usando o relógio normal. Portanto, o kernel não espera que os programas de espaço do usuário liberem explicitamente o processador (que é o caso da multitarefa cooperativa). Isso significa que um loop infinito em um programa de espaço do usuário não pode bloquear o sistema.
No entanto, até o kernel 2.6, o próprio kernel não era preemtível: assim que um thread entra no kernel, não é possível tentar executar outro thread. No entanto, essa ausência de preempção no kernel causou vários problemas com relação à latência e escalabilidade. Portanto, a preempção do kernel foi introduzida nos kernels 2.6 e é possível habilitá-lo ou desabilitá-lo usando a opção CONFIG_PREEMPT. Se CONFIG_PREEMPT estiver ativado, o código do kernel poderá ser antecipado em qualquer lugar, exceto quando o código tiver desativado as interrupções locais. Um loop infinito no código não pode mais bloquear todo o sistema. Se CONFIG_PREEMPT estiver desativado, o comportamento 2.4 será restaurado.
Solicitado e formatado de: http://www.linuxquestions.org/questions/linux-general-1/pre-emptive-vs-non-pre-emptive-kernel-582437/
Um kernel preemptivo permite que um processo seja antecipado enquanto está sendo executado no modo kernel. Um kernel não-preventivo não permite que um processo em execução no módulo do kernel seja antecipado; um processo no modo kernel será executado até sair do modo kernel, bloquear ou voluntariamente gerar o controle da CPU. Obviamente, um kernel não-preventivo está essencialmente livre de condições de corrida nas estruturas de dados do kernel, pois apenas um processo está ativo no kernel por vez. Não podemos dizer o mesmo sobre os kernels preventivos, portanto eles devem ser cuidadosamente projetados para garantir que os dados compartilhados do kernel estejam livres de condições de corrida. Os kernels preemptivos são especialmente difíceis de projetar para arquiteturas SMP, pois nesses ambientes é possível que dois processos no modo kernel sejam executados simultaneamente em diferentes processadores. Um kernel preemptivo é mais adequado para programação em tempo real, pois permitirá que um processo em tempo real adote um processo atualmente em execução no kernel. Além disso, um kernel preemptivo pode ser mais responsivo, pois há menos risco de que um processo no modo kernel seja executado por um período arbitrariamente longo antes de deixar o processador para processos em espera. Obviamente, esse efeito pode ser minimizado projetando o código do kernel que não se comporta dessa maneira. Mais adiante neste capítulo, exploraremos como vários sistemas operacionais gerenciam a preempção no kernel. esse efeito pode ser minimizado projetando o código do kernel que não se comporta dessa maneira. Mais adiante neste capítulo, exploraremos como vários sistemas operacionais gerenciam a preempção no kernel. esse efeito pode ser minimizado projetando o código do kernel que não se comporta dessa maneira. Mais adiante neste capítulo, exploraremos como vários sistemas operacionais gerenciam a preempção no kernel.