Eu tenho um sistema Linux em que usamos cgroups para criar dois cpusets cpu_exclusive, A e B, e onde migramos todos os threads de usuário e todos os threads de kernel não acoplados para um cgroup conectado ao cpuset A. Os itens em execução no cpuset A têm políticas de agendador variadas prioridades variadas e há muito mais threads em execução no cpuset A do que núcleos no cpuset A.
Também há um pequeno número de processos muito ativos conectados ao cpuset B, em que o número total de threads de usuário nesses processos nunca é maior que o número de núcleos disponíveis exclusivamente no cpuset B. O objetivo é proteger essas tarefas importantes em execução no cpuset B de outras atividades na máquina e para minimizar a latência de processamento.
Nessa configuração, a política / prioridade de agendamento dos threads do usuário em execução no cpuset B tem algum efeito observável? Em outras palavras: alterar a política de agendamento dos encadeamentos cpuset B do padrão SCHED_OTHER para SCHED_FIFO ou SCHED_RR teria alguma consequência, boa ou ruim?
Parece que a resposta deve ser 'não', pois o agendador deve poder atribuir a cada thread em execução no cpuset B seu próprio núcleo dedicado, para que não haja nada para priorizar ou agendar e, portanto, a política e a prioridade relativa do B threads cpuset não importam. Por outro lado, há os tópicos encadernados do kernel e os aspectos 'domínio do planejador' com os quais se preocupar, e provavelmente outras coisas que não considerei.
As políticas de agendamento e as prioridades dos threads em execução em um cpuset exclusivo com excesso de provisionamento são importantes em algum sentido prático?