Por que os primeiros desenvolvedores do 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. Que vantagem um kernel não-preventivo oferece nesses PCs? Por que, no entanto, a vantagem é reduzida pelos processadores com vários núcleos?
Respostas:
No contexto do kernel do Linux, quando as pessoas falam sobre prevenção, elas geralmente se referem à capacidade do kernel de se interromper - essencialmente, alterna tarefas enquanto executa o código do kernel. Permitir que isso aconteça é bastante complexo, o que provavelmente é a principal razão pela qual demorou muito tempo para o kernel tornar-se preemptivo.
No início, a maioria dos códigos do kernel não podia ser interrompida, pois estava protegida pelo grande bloqueio do kernel. Esse bloqueio foi progressivamente eliminado de cada vez mais códigos do kernel, permitindo várias chamadas simultâneas ao kernel em paralelo (que se tornaram mais importantes à medida que os sistemas SMP se tornaram mais comuns). Mas isso ainda não tornou o próprio kernel antecipado; isso levou mais desenvolvimento ainda, culminando no PREEMPT_RTconjunto de patches que foi eventualmente mesclado no kernel da linha principal (e foi capaz de antecipar o BKL de qualquer maneira). Atualmente, o kernel pode ser configurado para ser mais ou menos preventivo, dependendo das características de taxa de transferência e latência que você procura; veja a configuração do kernel relacionada para detalhes.
Como você pode ver pelas explicações na configuração do kernel, a prevenção afeta a taxa de transferência e a latência, não a simultaneidade. Nos sistemas de CPU única, a prevenção ainda é útil porque permite que os eventos sejam processados com tempos de reação mais curtos; no entanto, também resulta em menor taxa de transferência (já que o kernel gasta tempo alternando tarefas). A preferência permite que qualquer CPU, em um sistema único ou múltiplo, mude para outra tarefa mais rapidamente. O fator limitante nos sistemas com várias CPUs não é a prevenção, são bloqueios, grandes ou outros: a qualquer momento que um código é bloqueado, significa que outra CPU não pode começar a executar a mesma ação.
O kernel preemptivo significa apenas que não há Big Kernel Lock .
O Linux tinha multitarefa preemptiva (ou seja, o código do usuário era preemptivo) desde o primeiro momento (até onde eu sei, o primeiro Linux 0.0.1 carregado por Linus no servidor do funet ftp 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 - na época - amplamente utilizado Win31. No Win31, se uma tarefa obteve a CPU do "kernel", por padrão, era sua responsabilidade determinar quando devolver o controle ao SO (ou a outras tarefas). Se um processo não tiver suporte especial para esse recurso (que requer trabalho de programação adicional), durante a execução, todas as outras tarefas serão suspensas. Até os aplicativos mais básicos integrados ao Win31 funcionavam.
A multitarefa preemptiva significa que as tarefas não têm como alocar a CPU como desejam. Em vez disso, se o intervalo de tempo expirar, o kernel afastará a CPU deles. Portanto, em sistemas operacionais preventivos, um processo mal escrito ou com mau funcionamento não pode congelar o sistema operacional ou evitar a execução de outros processos. 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 montar vários sistemas de arquivos simultaneamente - se você der vários comandos de montagem, eles ainda serão executados consecutivamente, porque montar coisas necessárias para alocar o Big Kernel Lock.
Tornar o kernel preemptivo exigia eliminar esse grande bloqueio do kernel, ou seja, tornar o mount e quaisquer outras tarefas capazes de executar simultaneamente. Foi um grande trabalho.
Historicamente, isso foi realmente urgente pelo crescente suporte ao SMP (suporte a várias CPUs). Na primeira vez, havia realmente placas-mãe com várias CPUs. Mais tarde, várias CPUs ("núcleos") foram integradas em um único chip, hoje as placas-mãe com várias CPUs realmente são raras (normalmente em sistemas de servidor dispendiosos). Também os sistemas realmente de núcleo único (onde existe apenas uma única CPU, com um único núcleo) são raros.
Portanto, a resposta para sua pergunta não é "qual foi o motivo da não-preemptividade", porque sempre foi preemptiva. A verdadeira questão é: o que tornou realmente necessária a execução preventiva do kernel . A resposta é para isso: a proporção crescente de sistemas com muitas CPUs e muitos núcleos.
Esta não é uma resposta técnica, mas uma resposta histórica à pergunta específica colocada pelo OP: "Qual foi o motivo da não preferência dos kernels Linux mais antigos?"
(Suponho, como explicado por @peterh em suas respostas e comentários, que por "não prioridade" o OP está se referindo a um ou a ambos o fato de que apenas um processo de usuário pode estar dentro do kernel (em uma API) em um horário 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, ambiente básico e de desenvolvimento inicial era o Minix, um sistema operacional 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 deseja colocar seu novo sistema operacional em funcionamento rapidamente para fins educacionais: é muito mais simples assim. Um kernel para oferecer suporte à multiprogramação simultânea de programas e dispositivos do usuário já é bastante difícil - é extremamente difícil tornar o próprio kernel simultâneo.
Se ele soubesse o quão popular / útil / importante o Linux se tornaria ... ele provavelmente teria feito da mesma maneira. (Apenas na IMO, não tenho idéia do que ele realmente pensa.) Porque você precisa caminhar antes de poder correr.
E permaneceu assim por um bom tempo porque: a) havia muito outro trabalho a ser feito para tornar o Linux o que é hoje (ou mesmo o que era na época) eb) para mudar, seria uma tarefa difícil e importante (conforme explicado em outras respostas).