Se eu entrar em doisdiferenteterminais raiz:
nice -n 19 burnK7 &
e
nice -n -19 burnK7 &
Então, ambos os processos recebem cerca de 50% do tempo de CPU disponível - o que não é esperado e certamente não é desejado.
Se eu correr nomesmoterminal raiz:
nice -n 19 burnK7 &
nice -n -19 burnK7 &
O primeiro processo recebe cerca de 0% e o segundo recebe cerca de 100% do tempo de CPU disponível, conforme esperado.
isso é um erro ou uma característica?
Estou executando o Arch Linux com a versão 3.16 do kernel, em uma máquina de núcleo único, pelo que vale a pena.
Responder1
Então, bem depois do fato, aqui estão algumas informações. O comportamento que você está vendo é devido ao recurso de grupo automático que foi adicionado no Linux 2.6.38 (em 2010). Aqui está uma versão editada de algum texto que estou prestes a adicionar aosched(7)página de manualo que explica o que você está vendo.
O kernel fornece um recurso conhecido como agrupamento automático para melhorar o desempenho da área de trabalho interativa em face de cargas de trabalho com uso intensivo de CPU e multiprocessos, como a construção do kernel Linux com um grande número de processos de construção paralelos (ou seja, o make(1) -jsinalizador).
Um novo autogrupo é criado quando uma nova sessão é criada via setsid(2); isso acontece, por exemplo, quando uma nova janela de terminal é iniciada. Um novo processo criado por fork(2)herda a associação ao autogrupo de seu pai. Assim, todos os processos em uma sessão são membros do mesmo autogrupo.
Quando o agrupamento automático está ativado, todos os membros de um grupo automático são colocados no mesmo "grupo de tarefas" do agendador do kernel. O agendador do kernel Linux emprega um algoritmo que equaliza a distribuição dos ciclos de CPU entre grupos de tarefas. Os benefícios disso para o desempenho da área de trabalho interativa podem ser descritos no exemplo a seguir.
Suponha que existam dois autogrupos competindo pela mesma CPU (isto é, presuma um único sistema de CPU ou o uso de taskset(1)
para confinar todos os processos à mesma CPU em um sistema SMP). O primeiro grupo contém dez processos vinculados à CPU de uma compilação de kernel iniciada com make -j10. O outro contém um único processo vinculado à CPU: um reprodutor de vídeo. O efeito do agrupamento automático é que cada um dos dois grupos receberá metade dos ciclos da CPU. Ou seja, o player de vídeo receberá 50% dos ciclos da CPU, em vez de apenas 9% dos ciclos, o que provavelmente levaria à degradação da reprodução do vídeo. A situação em um sistema SMP é mais complexa, mas o efeito geral é o mesmo: o escalonador distribui ciclos de CPU entre grupos de tarefas de modo que um autogrupo que contém um grande número de processos vinculados à CPU não acabe sobrecarregando os ciclos de CPU às custas dos outros trabalhos no sistema.
O bom valor e agendamento de grupo
Ao agendar processos que não sejam em tempo real (por exemplo, aqueles agendados sob a SCHED_OTHERpolítica padrão), o escalonador emprega uma técnica conhecida como "agendamento de grupo", sob a qual os threads são agendados em "grupos de tarefas". Os grupos de tarefas são formados em diversas circunstâncias, sendo o caso relevante aqui o autoagrupamento.
Se o agrupamento automático estiver ativado, todos os threads que são (implicitamente) colocados em um grupo automático (ou seja, a mesma sessão criada por setsid(2)) formam um grupo de tarefas. Cada novo autogrupo é, portanto, um grupo de tarefas separado.
No agendamento de grupo, o bom valor de um thread afeta as decisões de agendamentoapenas em relação a outros threads no mesmo grupo de tarefas. Isto tem algumas consequências surpreendentes em termos da semântica tradicional do valor nice nos sistemas UNIX. Em particular, se o agrupamento automático estiver habilitado (que é o padrão em várias distribuições), então empregar nice(1)em um processo terá efeito apenas no agendamento relativo a outros processos executados na mesma sessão (normalmente: a mesma janela de terminal).
Por outro lado, para dois processos que são (por exemplo) os únicos processos vinculados à CPU em sessões diferentes (por exemplo, janelas de terminal diferentes, cada um dos quais trabalhos estão vinculados a grupos automáticos diferentes), modificando o valor legal do processo em uma das sessões não tem efeito em termos das decisões do escalonador relativas ao processo na outra sessão.
Se quiser evitar que o agrupamento automático interfira no nicecomportamento tradicional descrito aqui, você pode desativar o recurso
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
Esteja ciente, porém, de que isso também terá o efeito de desabilitar os benefícios de interatividade da área de trabalho que o recurso de grupo automático pretendia fornecer (veja acima).
O bom valor do autogrupo
A associação ao autogrupo de um processo pode ser visualizada por meio do arquivo /proc/[pid]/autogroup:
$ cat /proc/1/autogroup
/autogroup-1 nice 0
Este arquivo também pode ser usado para modificar a largura de banda da CPU alocada para um autogrupo. Isso é feito escrevendo um número no intervalo "nice" no arquivo para definir o valor nice do autogrupo. O intervalo permitido é de +19 (baixa prioridade) a -20 (alta prioridade).
A configuração agradável do autogrupo tem o mesmo significado que o valor agradável do processo, mas se aplica à distribuição de ciclos de CPU para o grupo automático como um todo, com base nos valores legais relativos de outros grupos automáticos. Para um processo dentro de um autogrupo, os ciclos de CPU que ele recebe serão um produto do valor agradável do autogrupo (em comparação com outros autogrupos) e do valor agradável do processo (em comparação com outros processos no mesmo autogrupo).