Quais são os efeitos, se houver, das prioridades e políticas do planejador para encadeamentos em um cpuset não contido?

Question

Eu tenho um sistema Linux onde usamos cgroups para criar dois cpus_exclusive cpusets, A e B, e onde nós migramos todos os threads do usuário e todos os encadeamentos do kernel não acoplados para um cgroup anexado ao cpuset A. As coisas rodando no cpuset A variando políticas de agendador e prioridades variáveis, e há muitos mais threads em execução no cpuset A do que núcleos no cpuset A.

Há também um pequeno número de processos muito ativos anexados ao cpuset B, onde o número total de threads do 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 executando no cpuset B de outra atividade na máquina e para minimizar a latência de processamento.

Em tal configuração, a política de agendamento / prioridade dos threads do usuário em execução no cpuset B tem algum efeito observável? Dito de forma diferente: mudar a política de programação dos encadeamentos do Bpuset do padrão SCHED_OTHER para SCHED_FIFO ou SCHED_RR tem alguma consequência, boa ou ruim?

Parece que a resposta deve ser 'não', já que o agendador deve ser capaz de atribuir a cada thread em execução no cpuset B seu próprio núcleo dedicado, de modo que não haveria nada para priorizar ou agendar e, portanto, a política e a prioridade relativa dos threads cpuset B não importaria. Por outro lado, existem os tópicos do kernel vinculado e os aspectos do 'domínio do planejador' para se preocupar, e provavelmente outras coisas que eu não considerei.

As políticas e prioridades de agendamento de threads em execução em um cpuset exclusivo superprovisionado importam em qualquer sentido prático?

    

Answer 1

O intervalo de tempo usado será importante para trabalhos intensivos da CPU que exigem persistência do cache, a menos que você bloqueie um núcleo específico para cada PID. Você pode aumentar o intervalo de tempo com a política SCHED_BATCH do agendador e melhorar o desempenho em até 300% em alguns casos, reduzindo a capacidade de resposta interativa. O efeito oposto de fatias de tempo menores ocorre com SCHED_RR (que reduzirá a taxa de transferência, mas aumentará a capacidade de resposta em tempo real).

Você pode usar schedtool para definir a política de PIDs específicos para todos os PIDs no conjunto B como um único comando. Ele também pode ser usado para bloquear PIDs específicos para núcleos específicos, o que seria a solução ideal, pois a persistência do cache não depende mais do intervalo de tempo, mas isso exige mais esforço, pois é necessário executar um comando schedtool separado para cada PID. / p>     

Answer 2

Se cada processo tiver seu próprio núcleo, não haverá restrições de prioridade.

No entanto, se você programar um processo que leve 30 minutos para ser executado a cada 15 minutos, começará a ter a necessidade de priorizar, pois o processo começará a se sobrepor.

No entanto, não há uma política de programação "melhor".

Eles realmente dependem do que você deseja alcançar. Mas no começo, eu deixava o SCHED_OTHER, o padrão, e observava por algum tempo antes de tentar algo mais especializado.