Por que o patch do kernel -rt (RT-Preempt) não é incluído por padrão no kernel da linha principal?

Question

De acordo com o link , o patch RT-Preempt converte o Linux em um kernel completamente preempitivo. A mágica é feita por:

1. Tornando primitivos de bloqueio no kernel (usando spinlocks) preemptivos, embora reimplementados com rtmutexes.
2. As seções críticas protegidas por, por exemplo, spinlock_t e rwlock_t agora são preemptivas. A criação de seções não preemptivas (no kernel) ainda é possível com raw_spinlock_t (mesmas APIs como spinlock_t)
3. Implementando a herança de prioridade para mutexes, spinlocks e rw_semaphores no kernel.
4. Convertendo manipuladores de interrupção em encadeamentos preemptivos do kernel: O patch RT-Preempt trata os manipuladores de interrupção soft no contexto do encadeamento do kernel, que é representado por um task_struct como um processo de espaço de usuário comum. No entanto, também é possível registrar um IRQ no contexto do kernel.
5. Convertendo a antiga API do timer do Linux em infraestruturas separadas para timers de kernel de alta resolução, mais um para tempos limite, levando a timers POSIX de espaço do usuário com alta resolução.

Há alguma desvantagem de ser em tempo real, em vez de apenas multitarefa?

    

Answer 1

O patch do kernel -rt (RT-Preempt) não está na linha principal do kernel porque o Kernel do Linux está focado na implementação de um kernel para uso geral, e o multi-tasking foi uma escolha de Linus Torvalds quando ele começou a implementá-lo .

É curioso porque o kernel é como é. A resposta é que é assim porque Linus escolheu esse caminho. E por que ele escolheu esse caminho? Porque ele acreditou que era o melhor caminho, ou a maneira possível de implementá-lo.

Algumas pessoas acham que outros conceitos de design são melhores que os reais. Mas é impossível dizer isso. Cada um tem sua própria opinião e, às vezes, não há como compará-lo devido à complexidade e às possibilidades.

Existe a discussão clássica entre Linus Torvalds e Andrew Tanenbaum sobre monolítico versus microkernel. E há muitos argumentos para dizer que cada um é um modelo melhor.

Da mesma forma, há multitarefa e em tempo real. Qual é o melhor? Cada um tem suas próprias vantagens e desvantagens.

Em suma, o kernel principal não vem corrigido para ser em tempo real. Simples! Isso é apenas por causa das escolhas e crenças do desenvolvedor!

    

Answer 2

Isso é baseado em opinião, então leve para o que vale a pena.

Qualquer decisão de engenharia é sobre equilibrar o trade-off. O patch -rt é sobre o determinismo no tempo de manipulação. Trata-se de ter certeza de que as coisas serão executadas no momento certo. Lembre-se do velho ditado:

real-time is when the right answer at the wrong time is wrong

Mas o uso típico não é sobre o tempo real. O Vanilla Linux é bom o suficiente nesta área para uso típico, por isso não precisa do patch -rt. Usando o patch -rt, o sistema provavelmente será mais lento para um uso típico.

Como -rt não adiciona nada útil para o usuário típico, diminui o desempenho típico da carga de trabalho, ele não é incluído nas distribuições usuais do kernel.

Definitivamente há usos para o patch -rt, então é muito bom que ele seja incluído como parte padrão do código-fonte do kernel. Agora é simplesmente uma escolha a fazer quando se constrói o kernal (há muitas opções disponíveis em várias áreas ao construir um kernal). Se sua carga de trabalho for aprimorada pelo patch -rt, selecione um kernal que o tenha ativado (ou construa-o especificamente adaptado à sua situação).