Qual foi o motivo da não preemptivity de kernels mais antigos do Linux?

Question

Por que os primeiros desenvolvedores de Linux optaram por implementar um kernel não preventivo? É para salvar a sincronização?

Até onde eu sei, o Linux foi desenvolvido no início dos anos 90, quando os PCs tinham um único processador. Qual a vantagem de um kernel não preventivo em tais PCs? Por que, no entanto, a vantagem é reduzida pelos processadores multi-core?

    

Answer 1

No contexto do kernel do Linux, quando as pessoas falam sobre preempção, elas geralmente se referem à capacidade do kernel de interromper a si mesmo - essencialmente, alternar tarefas durante a execução do código do kernel. Permitir que isso aconteça é bastante complexo, o que provavelmente é a principal razão pela qual levou muito tempo para o kernel se tornar preemptível.

No início, a maioria dos códigos do kernel não podia ser interrompida de qualquer maneira, já que era protegida pelo grande bloqueio do kernel. Esse bloqueio foi progressivamente eliminado de mais e mais códigos do kernel, permitindo múltiplas chamadas simultâneas ao kernel em paralelo (o que se tornou mais importante à medida que os sistemas SMP se tornaram mais comuns). Mas isso ainda não tornou o kernel em si preemptível; que levou ainda mais desenvolvimento, culminando no conjunto de patches PREEMPT_RT que acabou sendo mesclado no kernel mainline (e era capaz de antecipar o BKL de qualquer maneira). Atualmente, o kernel pode ser configurado para ser mais ou menos preemptível, dependendo das características de taxa de transferência e latência que você procura; veja a configuração de kernel relacionada detalhes.

Como você pode ver nas explicações na configuração do kernel, a preempção afeta a taxa de transferência e a latência, não a simultaneidade. Em sistemas de CPU única, a preferência ainda é útil porque permite que os eventos sejam processados com tempos de reação mais curtos; no entanto, isso também resulta em menor taxa de transferência (já que o kernel gasta tarefas de comutação de tempo). A preempção permite que qualquer CPU, em um sistema de CPU único ou múltiplo, mude para outra tarefa mais rapidamente. O fator limitador em sistemas com várias CPUs não é de prevenção, são bloqueios, grandes ou não: qualquer código de tempo bloqueia, isso significa que outra CPU não pode começar a realizar a mesma ação.

    

Answer 2

Somente o kernel preventivo significa que não há Big Kernel Lock .

O Linux tinha multitarefa preventiva (isto é, o código do usuário era preemptivo) desde o seu primeiro momento (até onde eu sei, o muito primeiro Linux 0.0.1 carregado pelo Linus para o servidor ftp do funet já era multitarefa preemptiva). Se você executou, por exemplo, vários processos de compactação ou compilação, eles foram executados paralelamente desde o primeiro momento.

Ao contrário do - no momento - amplamente utilizado Win31. No Win31, se uma tarefa obtinha a CPU do "kernel", por padrão, era sua responsabilidade determinar quando devolver o controle ao sistema operacional (ou a outras tarefas). Se um processo não tiver suporte especial para esse recurso (o que exigiu trabalho de programação adicional), então, durante a execução, todas as outras tarefas foram suspensas. Até mesmo a maioria dos aplicativos básicos integrados ao Win31 funcionaram.

Multitarefa preventiva significa que as tarefas não têm como alocar a CPU como quiserem. Em vez disso, se o seu intervalo de tempo expirar, o kernel afasta a CPU deles. Assim, em sistemas operacionais preventivos, um processo mal escrito ou mal-funcionante não pode congelar o SO ou evitar que outros processos sejam executados. O Linux sempre foi preventivo para processos de espaço do usuário.

O Big Kernel Lock significa que, em alguns casos, dentro do espaço do kernel , ainda pode haver alguns bloqueios, impedindo que outros processos executem o código protegido. Por exemplo, você não pode vários sistemas de arquivos simultaneamente - se você deu vários comandos de montagem, eles ainda foram executados consecutivamente , porque monta as coisas necessárias para alocar o Big Kernel Lock.

Tornar o preemptive do kernel necessário para eliminar esse grande bloqueio do kernel, ou seja, fazer com que a montagem e quaisquer outras tarefas possam ser executadas simultaneamente. Foi um grande trabalho.

Historicamente, isso foi realmente urgente pelo suporte crescente do SMP (suporte a múltiplas CPUs). Na primeira vez, havia placas-mãe realmente com múltiplas CPUs. Mais tarde várias CPUs ("núcleos") foram integradas em um único chip, hoje as mainboards realmente multi-CPU já são raras (elas são tipicamente em sistemas de servidor caros). Também os sistemas realmente single-core (onde há apenas uma única CPU, com um único núcleo) são raros.

Assim, a resposta à sua pergunta não é "qual foi o motivo da não-preemptividade", porque sempre foi preventiva. A verdadeira questão é: o que tornou a execução preventiva do kernel realmente necessária . A resposta é para isso: a taxa crescente dos muitos sistemas de muitos núcleos de CPU.

    

Answer 3

Esta não é uma resposta técnica, mas uma resposta histórica à questão específica apresentada pelo OP: "Qual foi o motivo da não preemptividade dos kernels mais antigos do Linux?"

(Eu assumo, como explicado por @ Peter em sua resposta e comentários, que por "não preemptivity" o OP está se referindo a um ou ambos do fato de que apenas um processo de usuário poderia estar dentro do kernel (em uma API) ) por vez e / ou o Big Kernel Lock.)

Linus Torvalds estava interessado em aprender como os sistemas operacionais funcionavam, e a maneira como ele aprendeu foi escrever um. Seu modelo, base e ambiente de desenvolvimento inicial era o Minix, um SO existente para fins educacionais (ou seja, não um sistema operacional de produção) que não era gratuito (como no código aberto, na época - não era livre como na cerveja, ou).

Então ele escreveu um kernel sem preempção (o Big Kernel Lock mencionado em outras respostas) porque é assim que você faz se quiser que seu novo sistema operacional funcione rapidamente para fins educacionais: é muito muito mais simples dessa maneira. Um kernel para suportar multiprogramação simultânea de programas e dispositivos de usuários é bastante difícil - é extremamente difícil fazer o próprio kernel concorrente.

Se ele soubesse então como o popular / útil / importante Linux se tornaria ... ele provavelmente teria feito da mesma maneira. (IMO apenas, eu não tenho ideia do que ele realmente pensa.) Porque você tem que andar antes de poder correr.

E ficou assim por muito tempo porque a) havia muito trabalho a ser feito para tornar o Linux o que é hoje (ou até mesmo o que era então) eb) mudar isso seria um grande empreendimento difícil (como explicado em outras respostas).