A página do manual está correta. Não deve ser difícil encontrar uma confirmação disso.
/* * SCHED_DEADLINE tasks has negative priorities, reflecting * the fact that any of them has higher prio than RT and * NORMAL/BATCH tasks. */ #define MAX_DL_PRIO 0
Esta foi a abordagem escolhida pelo mantenedor do programador Linux. Eu citei a explicação do LWN abaixo, embora você deva desejar ler todo o artigo do LWN que se torne relevante para seus interesses. Como estes são finitos em extensão, não posso garantir que eles resolvam cada confusão específica que você possa ter. link
Peter Zijlstra, though, thinks that deadline scheduling should run at the highest priority; otherwise it cannot ensure that the deadlines will be met.
I'm a bit confused since I thought rtprio 99 would be the highest priority in the system (watchdogs, migration, posixcputimer...)
O LWN vincula-se à revisão inicial de Peter, que menciona isso.
The only two tasks that need to be the absolute highest priority are kstopmachine and migrate, so those would need to be lifted above EDF, the rest is not important :-)
Eu não sei exatamente o que migrar seria esse contexto, mas o artigo do LWN chama o SMP em tempo real como um desafio.
stopmachine está na lista que diz "não faça isso para RT", por esse motivo. Peter torna isso explícito mais tarde .
Os cães de guarda certamente operam em escalas de tempo maiores do que os processos em tempo real, e o agendamento de prazos deixará tempo para serem executados mais tarde (veja abaixo).
Ironicamente, estou lutando para encontrar informações sobre o comportamento dos timers no kernel em tempo real. Há um RT wiki que menciona isso para prioridades, mas não prazos ... note que a página foi editada pela última vez 2008 e especifica uma máquina de teste com uma CPU PIII 400 Mhz. Também é interessante que Peter não tenha mencionado os temporizadores na revisão inicial. Parece que os processos RT foram encorajados a usar clock_nanosleep (), se possível. (Claramente isso teria pouca ou nenhuma utilidade para os relógios CPUTIME, que podem ser o que você está se referindo).
O programador de prazos tem o potencial de garantir que os prazos sejam cumpridos, desde que os processos não excedam o tempo de execução de pior caso especificado. O agendador de prioridades não possui esse recurso.
Os mantenedores favoreceram essa garantia, em vez de torná-la condicional se um processo SCHED_FIFO está presente. A programação do prazo sem a garantia seria uma besta diferente ... se isso teria ou não alguma utilidade; Eu não sei realmente.
Os processos programados de prazo final têm uma largura de banda máxima - o que é imposto pelo planejador do Linux. Em princípio, deve ser possível observar a largura de banda total dos processos programados de prazo final, bem como o maior período de execução, e determinar o efeito de pior caso em qualquer processo agendado prioritário. O inverso não seria verdadeiro, porque não há aplicação de WCET para a classe de agendamento POSIX SCHED_FIFO.
A deadline system does away with static priorities. Instead, each running task provides a set of three scheduling parameters:
- A deadline - when the work must be completed.
- An execution period - how often the work must be performed.
- The worst-case execution time (WCET) - the maximum amount of CPU time which will be required to get the work done.
The "bandwidth" requirement of a process - what percentage of a CPU it needs - is easily calculated, so the scheduler knows at the outset whether the system is oversubscribed or not. The scheduler can (and should) refuse to accept tasks which would require more bandwidth than the system has available. By refusing excess work, the scheduler will always be able to provide the requisite CPU time to every process within the specified deadline. That kind of promise makes realtime developers happy.