A diferença é que o PR é uma prioridade real de um processo no momento dentro do kernel e a NI é apenas uma dica para o kernel qual a prioridade que o processo deve ter.
Na maioria dos casos, o valor do PR pode ser calculado pela seguinte fórmula: PR = 20 + NI . Assim, o processo com gentileza 3 tem a prioridade 23 (20 + 3) e o processo com gentileza -7 tem a prioridade 13 (20 - 7). Você pode verificar a primeira de comando em execução nice -n 3 top
. Isso mostrará que o processo principal possui NI 3 e PR 23 . Mas para rodar nice -n -7 top
na maioria dos sistemas Linux, você precisa ter privilégios de root, porque, na verdade, o menor valor de PR é a maior prioridade real. Assim, o processo com PR 13 tem prioridade mais alta do que os processos com prioridade padrão PR 20. É por isso que você precisa ser root. Mas o valor mínimo de gentileza permitido para processos não raiz pode ser configurado em /etc/security/limits.conf .
Teoricamente, o kernel pode alterar o valor do PR (mas não o NI ) por si só. Por exemplo, pode reduzir a prioridade de um processo se consumir muita CPU ou aumentar a prioridade de um processo se esse processo não tiver chance de ser executado por um longo tempo devido a outros processos de prioridade mais alta. Nesses casos, o valor do PR será alterado pelo kernel e o NI permanecerá o mesmo, portanto, a fórmula "PR = 20 + NI" não estará correta. Portanto, o valor da NI pode ser interpretado como uma dica para o kernel qual a prioridade que o processo deve ter, mas o kernel pode escolher prioridade real ( valor PR ) por conta própria, dependendo da situação. Mas geralmente a fórmula"PR = 20 + NI" está correto.
As regras exatas de como o kernel altera a prioridade não são claras. O manual setpriority (a função que altera o bom valor) diz:
O efeito da alteração do valor agradável pode variar dependendo do algoritmo de agendamento de processos em vigor.
Pthread manual diz o seguinte:
A prioridade dinâmica é baseada no valor nice (definido por nice (2), setpriority (2) ou sched_setattr (2)) e aumentada para cada quantum de tempo em que o encadeamento está pronto para ser executado, mas negado para ser executado pelo planejador.
Parece que o valor PR corresponde à prioridade dinâmica.
O intervalo do valor de NI é -20..19 . Assim, o valor PR pode ter valores de 0 (20 - 20) a 39 (20 + 19). Mas está correto apenas para os processos com política de agendamento padrão ( SHED_OTHER ). Também pode haver processos com as chamadas políticas de agendamento "em tempo real" . Essas políticas são SCHED_RR e SCHED_FIFO . Esses processos têm um valor PR menor que 0. Você pode verificar isso executando o chrt -r 1 top
comando (precisa ser root). O processo superior terá PR -2 . Você pode até executar chrt -r 90 top
, nesse caso, o topoprocesso terá PR -91 .
Parece que para processos SCHED_RR o valor PR pode ser calculado pela fórmula:
PR = - 1 - sched_rr_priority .
Portanto, um processo SCHED_RR possui pelo menos PR -1, o que significa que qualquer processo SCHED_RR tem prioridade mais alta que qualquer SCHED_OTHER . Isso corresponde ao manual pthread:
SCHED_FIFO pode ser usado apenas com prioridades estáticas maiores que 0, o que significa que quando um encadeamento SCHED_FIFO se torna executável, ele sempre antecipa imediatamente qualquer encadeamento SCHED_OTHER, SCHED_BATCH ou SCHED_IDLE em execução no momento.
SCHED_RR é um aprimoramento simples de SCHED_FIFO. Tudo o que foi descrito acima para SCHED_FIFO também se aplica a SCHED_RR,
A prioridade dos processos em tempo real é referida como prioridade estática que não pode ser alterada pelo kernel. Portanto, valores PR positivos podem ser tratados como prioridade dinâmica para processos não em tempo real ( SCHED_OTHER , SCHED_BATCH ) e valor PR negativo como prioridade estática para processos em tempo real ( SCHED_RR , SCHED_FIFO ).
Eu também tentei correr nice -n 10 chrt -r 50 top
(e chrt -r 50 nice -n 10 top
). O valor do NI era 10, mas o PR ainda era -51 . Portanto, parece que o valor da NI não afeta a prioridade dos processos SCHED_RR . Isso corresponde ao manual de prioridade :
Quaisquer processos ou threads que usem SCHED_FIFO ou SCHED_RR não serão afetados por uma chamada para setpriority (). Isso não é considerado um erro. Um processo que posteriormente reverte para SCHED_OTHER não precisa ter sua prioridade afetada por uma chamada setpriority ().
Uma nota engraçada. Se você executar chrt -r 99 top
, verá o valor RT em vez de um número na coluna PR .
PID USER PR NI VIRT RES SHR% CPU% MEM TIME + COMMAND
28489 root RT 0 2852 1200 896 R 0 0.1 0: 00.01 topo
Eu não acho que isso significa que o processo agora é especial. Eu acho que isso significa que a parte superior simplesmente não imprime -100 porque seriam necessários 4 caracteres para imprimir.
Você também pode usar htop em vez de top em todos os exemplos que podem ser mais convenientes. ps -l
também pode ser usado, mas o ponto base que separa prioridades em tempo real e não em tempo real não é 0, mas 60, portanto, nice -n -20 ps -l
será impresso
FS UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 R 0 28983 28804 0 60 -20-1176 - pts / 6 00:00:00 ps