Por que a gentileza varia de -20 a 19?

22

O nicecomando permite ajustar a prioridade de agendamento ("gentileza") de um programa. Em todos os sistemas do tipo Unix que usei, a gentileza é especificada por um número inteiro, onde -20 é a prioridade de agendamento mais favorável, 0 é o padrão e 19 é o menos favorável.

Ter 0 como a gentileza padrão é bastante intuitivo, mas por que -20 e 19 foram selecionados como pontos finais do intervalo? Por que não -128 e 127, que caberia exatamente em um byte de 8 bits assinado? Ou por que não -100 a 100, o que é mais intuitivo para humanos de mente decimal, ou similarmente, mas um pouco mais ergonomicamente, -99 a 99? O intervalo de -20 a 19 foi selecionado arbitrariamente ou tem algum relacionamento com os internos do agendador com os quais a niceinterface original era originalmente? (Entendo que hoje não existe esse relacionamento, pelo menos para o Linux, cujo planejador usa prioridades no intervalo de 0 a 139. No entanto, estou interessado nos motivos históricos do intervalo de -20 a 19).

— Psychonaut
fonte

4

Não consigo encontrar uma referência explicando por que esse intervalo específico foi escolhido, mas observe que na V7 a prioridade se encaixa em um byte assinado - consulte proc.h - e a função setpri define a prioridade como min(127, (recent CPU usage on a scale of 0 to 15) + 50 + pp->p_nice - 20), e as prioridades <25 foram reservadas para processos fazendo coisas ininterruptas. Então, a gentileza tinha que ser um tipo limitado.

— Mark Plotnick

7

Os níveis de gentileza interna são de 0 a 39, mas os incrementos são positivos ou negativos. Fonte . Portanto, a resposta é que os números (positivos e negativos) aceitos pelo nicecomando são o que leva você de 20, o nível padrão, para qualquer lugar no intervalo de 0 a 39.

Então, por que 0-39? O intervalo específico foi o que funcionou na implementação original dos designers. A razão pela qual valores mais positivos são mais agradáveis é que o bom nível é adicionado ao uso recente da CPU de um processo na determinação da prioridade. Para fornecer uma programação aproximada de rodízio, o kernel monitora a quantidade de CPU que cada processo havia queimado recentemente e alterna para processos que não tiveram tanto. Quanto mais alto o nível agradável, mais tempo de CPU parece ter o processo e mais frequentemente o agendador colocará esse processo no modo de suspensão ou no sono. Consulte O design do sistema operacional UNIX de Maurice J. Bach, Prentice-Hall 1986, sec. 8.1 (8.1.4 para especificidade). ISBN 0-13-201799-7.

— cxw
fonte

1

Você está enganado ao assumir que o agendador colocará um processo em suspensão se ele tiver um valor ruim. Em vez disso, o planejador não ativará um processo inativo se houver outros processos prontos para execução e esses processos tiverem um nível melhor e mais agradável. Observe que um processo é colocado no modo de suspensão, quando ele chama um syscall que impõe um modo de suspensão dos recursos ou quando um processo usa o quantum da CPU e há outros processos mais privilegiados aguardando a CPU.

— schily 27/09/15

-4

Você está enganado: Se você está em um UNIX em que a interface nice () ainda faz sentido, NZEROé o valor nice padrão e NZERO is 20.

Para tornar as coisas mais óbvias: você perguntou sobre o comando nicee, ao mesmo tempo, mencionou níveis absolutos, mas o comando nice não gerencia valores absolutos, mas sim incrementa relativamente ao nível atual. No caso do estado padrão, o nível legal NZEROé 20.

Valores agradáveis são 0..2 * NZERO-1 ou 0..39

Observe que, embora o planejador UNIX padrão ainda possa fazer algo útil com um bom valor, não há sentido no caso de você estar usando um planejador especializado, por exemplo, um planejador em tempo real.

— esperto
fonte

2

Você parece estar confundindo a interface do shell e a interface C. Esta pergunta é sobre o nicecomando shell.

— Gilles 'SO- stop be evil'

Bem, é você quem confunde as coisas. O comando nice só conhece deltas, mas a pergunta menciona valores agradáveis. A pergunta era sobre bons valores e eu respondi isso.

— schily 27/09/2015