O Kernel Linux estuda remover o RT_GROUP_SCHED, 'broken beyond repair'. Entenda o impacto no agendamento de tempo real e alternativas como HCBS. Confira a análise técnica completa.
O kernel Linux está prestes a se despedir de uma funcionalidade que, embora tenha sido projetada com boas intenções, tornou-se um fardo técnico para os desenvolvedores e para as distribuições. Trata-se do RT_GROUP_SCHED, o mecanismo de agendamento em grupo para tarefas de tempo real utilizando cgroups.
O engenheiro da Linutronix, Sebastian Andrzej Siewior, propôs um patch para remover completamente o CONFIG_RT_GROUP_SCHED, descrevendo o recurso como “broken beyond repair” (quebrado além do reparo).
Este artigo oferece uma análise aprofundada sobre os motivos técnicos dessa remoção, o que isso significa para o ecossistema Linux e quais são as alternativas em desenvolvimento. O conteúdo é baseado em fontes primárias como a lista de discussão do kernel (LKML) e os patches submetidos, .
O que é o RT_GROUP_SCHED e por que ele falhou?
O RT_GROUP_SCHED foi projetado na era do cgroups v1 para permitir que administradores atribuíssem largura de banda de tempo real a grupos de tarefas.
A ideia era simples: em vez de limitar apenas o sistema como um todo, seria possível criar “fatias” de CPU para grupos específicos, garantindo que tarefas SCHED_FIFO ou SCHED_RR de um grupo não monopolizassem o processador.
No entanto, o mundo evoluiu para o cgroups v2, e o RT_GROUP_SCHED não acompanhou essa transição.
Conforme explicado por Siewior, quando o recurso está habilitado, não é possível definir a política de uma tarefa para SCHED_{FIFO|RR} porque o cgroup ao qual ela pertence não possui tempo de execução (runtime) atribuído. E o mais crítico: o runtime não pode ser atribuído com o cgroups v2.
“O grupo raiz tem todo o runtime atribuído, o que significa que o parâmetro global do sysctl (sched_rt_runtime_us) não pode ser reduzido, pois a nova largura de banda será menor do que a atualmente disponível.”
Além disso, embora seja possível agendar tarefas SCHED_DEADLINE, o controle de admissão fica travado e só pode ser desabilitado via -1 no mesmo parâmetro sysctl.
O resultado prático é que todas as principais distribuições — Debian, openSUSE, Fedora e Arch Linux — já desabilitam o RT_GROUP_SCHED por padrão. O systemd também não oferece suporte ao recurso, o que reforça seu status de abandono.
A justificativa técnica para a remoção
O patch submetido por Siewior não é uma medida impulsiva; é o reconhecimento de que o custo de manter o RT_GROUP_SCHED supera em muito seus benefícios.
A proposta remove 1.438 linhas de código e adiciona apenas 15, enxugando significativamente a árvore do scheduler de tempo real (kernel/sched/rt.c).
Siewior argumenta que não há necessidade de consertar o RT_GROUP_SCHED porque o DL fair server já lida com o mecanismo de throttling de tempo real. Mais importante ainda, há um trabalho em andamento para substituí-lo por uma solução teoricamente sólida: o Hierarchical Constant Bandwidth Server (HCBS).
“Há trabalho no Hierarchical Constant Bandwidth Server (HCBS) que visa agrupar múltiplas tarefas de tempo real dentro de uma configuração de deadline.”
O HCBS está sendo desenvolvido por Yuri Andriaccio e já conta com múltiplas revisões (v6) na lista de discussão do kernel.
O objetivo é substituir o RT_GROUP_SCHED por um mecanismo mais robusto e teoricamente fundamentado, que permita reservas de largura de banda para cgroups que executam tarefas SCHED_FIFO/SCHED_RR, mas com suporte adequado ao cgroups v2.
O que muda na prática para desenvolvedores e administradores?
Para a grande maioria dos usuários, nada muda. Como as distribuições já desabilitam o RT_GROUP_SCHED, o patch apenas oficializa uma realidade de facto. A remoção elimina a necessidade de manter um código complexo e problemático, reduzindo a superfície de bugs no scheduler.
No entanto, para ambientes que ainda dependem do RT_GROUP_SCHED — algo que, segundo a discussão no LKML, pode existir em nichos não especificados —, a recomendação é desabilitá-lo no boot usando o parâmetro rt_group_sched=0.
A remoção completa do CONFIG_RT_GROUP_SCHED tornará essa opção de compilação obsoleta.
O patch ainda não foi mesclado, e surgiram questionamentos sobre a existência de usuários remanescentes e a possibilidade de primeiro marcar a opção como deprecated antes da remoção definitiva.
Contudo, o consenso na lista de discussão parece ser favorável à remoção, com “amor” à ideia de se livrar do código problemático.
Alternativas e o futuro do agendamento de tempo real
A aposta do kernel Linux para o futuro do agendamento hierárquico de tempo real é o HCBS.
Este mecanismo é baseado no Compositional Scheduling Framework (CSF) e permite que cgroups atuem como “task runners” ou como “bandwidth reservation” (reserva de largura de banda), oferecendo um controle mais granular e teoricamente correto.
Enquanto o HCBS não é totalmente integrado, o DL fair server continua sendo a solução para o throttling de tempo real, garantindo que o sistema permaneça responsivo mesmo sob cargas de trabalho intensas.
A remoção do RT_GROUP_SCHED é, portanto, um passo necessário para limpar o terreno e permitir que a nova arquitetura floresça sem as amarras do código legado.
Checklist para acompanhar a transição
□ Verifique se o kernel da sua distribuição ainda compila com CONFIG_RT_GROUP_SCHED=y.
□ Se for necessário desabilitar o recurso no boot, adicione rt_group_sched=0 à linha de comando do kernel.
□ Monitore os patches do HCBS na LKML para acompanhar a evolução da alternativa.
□ Esteja atento ao sched_rt_runtime_us para ajustes de largura de banda de tempo real.
□ Considere migrar cargas de trabalho de tempo real para configurações baseadas em SCHED_DEADLINE ou aguardar a maturidade do HCBS.
Questionário rápido
a) Porque é muito lento.
b) Porque não funciona corretamente com o cgroups v2 e impede a atribuição de runtime.
c) Porque não suporta SCHED_DEADLINE.
Resposta correta: b)
2. Qual é a principal alternativa em desenvolvimento para substituir o RT_GROUP_SCHED?
a) CFS (Completely Fair Scheduler).
b) HCBS (Hierarchical Constant Bandwidth Server).
c) RSDL (Rotating Staircase Deadline Scheduler).
Resposta correta: b)
3. O que acontece com as distribuições que já desabilitam o RT_GROUP_SCHED quando o patch for mesclado?
a) Elas precisarão reabilitá-lo.
b) Elas não serão afetadas, pois a mudança apenas oficializa o estado atual.
c) Elas perderão suporte a tarefas de tempo real.
Resposta correta: b)
Conclusão
A remoção do RT_GROUP_SCHED é um exemplo claro de como o kernel Linux evolui: funcionalidades que não acompanham as mudanças arquiteturais (como a transição para o cgroups v2) são substituídas por soluções mais robustas.
Para os entusiastas e profissionais de sistemas embarcados e de tempo real, o recado é claro: o futuro pertence ao HCBS. Acompanhar essa transição é essencial para quem deseja manter sistemas Linux atualizados e alinhados com as melhores práticas de agendamento de tempo real.
Nenhum comentário:
Postar um comentário