Opção em tempo real no ulimit

Question

A chamada de ulimit -a retorna o seguinte:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1895
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1895
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

O que faz a opção -r (tempo real)?

    

Answer 1

TL-DR : é a prioridade mais alta (= mais urgente) que processos gerados por shell podem ser atribuídos pelo agendador.

Explicação do Word

dá controle sobre os recursos disponíveis para o shell : relata e / ou define tais limites.

O sinalizador -r informa a prioridade mais alta a ser atribuída para o planejamento a um processo gerado pelo shell. Como as prioridades são executadas de 0 (mais urgente) para 99 (menos urgente), isso significa que processos gerados pelo shell (aqueles pertencentes às classes de aplicativo em tempo real) < em> pode alcançar as maiores prioridades de programação.

Os processos são classificados com base no uso de recursos ( limite de E / S ou limite de CPU , dependendo se eles usam principalmente E / S ou Recursos da CPU) ou, mais relevante aqui, com base no seu grau de urgência (uma expressão não técnica). Existem processos interativos como o shell : uma vez que nós humanos somos lentos e burros, o pc perde muito tempo esperando que levantemos um dedo. Entretanto, uma vez que uma tecla tenha sido pressionada, esses processos precisam ter alta prioridade, a menos que sintamos que o sistema se tornou sem resposta ; os atrasos médios devem ser de ordem 50msec ou mais, e com pequena variação.

Existem também processos em lote , que não precisam de interação com o usuário, são executados principalmente em segundo plano, portanto, recebem baixa prioridade pelo planejador. Um exemplo típico são cálculos científicos.

Por último, existem processos em tempo real que impõem as restrições mais rigorosas no escalonador. Nesta categoria, a queda de vídeo e gravações de áudio e reprodução, coleta de dados de sensores físicos, controladores de robôs. Esses processos devem receber a mais alta prioridade para permitir que eles executem suas tarefas.

O fato de que tal prioridade, como relatada por ulimit , é 0 não significa que isso é necessariamente 0 : 0 é o limite rígido, você pode definir um limite soft com valores menores, e você pode aumentar a prioridade até o valor do limite hard , que no entanto neste caso também coincide com o máximo disponível no sistema.