Frage zu Schedulerquellcode

[Lutz Donnerhacke]

* Johannes Nicolai wrote:
>Nach meiner Erkenntnis setzt der Scheduler task->priority bei einem Task mit
>der Priorität SCHED_FIFO (Realtimeprozess, der nur Kontrolle abgibt, wenn es
>einen Prozess mit höherer Realtimepriorität gibt) nicht wieder auf
>task->rt_priority (wie z.B. bei Taks der Klasse SCHED__RR), sondern lässt es
>auf 0. Nach meiner Meinung führt dass zu kleinen Performanceeinbußen, da der
>Task spätestens nach 10 ms (Timerinterrupt, der dann task->need_resched
>setzt) in den Scheduler zurückkommt, nur um dann wieder ausgewählt zu
>werden.

SCHED_FIFO ist im lt. Ada RealTime Spezifikation unterbrechbar, aber mit der
Randbedingung, wieder fortgesetzt zu werden, falls nichts neues dazwischen
kommt. Eine genaue Spezifikation findet sich im Appendix 'D Real-Time
Systems (normative)' http://www.adapower.com/rm95/arm95_284.html#SEC284

Die passende Rationale http://www.adapower.com/rationale/rat95-p3-d.html ist
dafür etwas mager. http://www.deja.com/=dnc/getdoc.xp?AN=626865365 führt
weiter.

>2. Ein Task der Schedulingpriorität SCHED_RR (Realtimetask
>mit POSIX-Round-Robin-Verfahren (gibt auch an Tasks mit derselben
>Realtimepriorität ab und reiht sich hinten an)) verhält sich so, wie ein
>SCHED_RR Prozess (er gibt einfach durch einen kleinen Bug die Kontrolle an
>gleichwertige Tasks nicht ab).

Auch dafür ist die Konsultation des Threads auf Deja hilfreich.

[Linus angeschrieben]
>Auf diese Mail bekam ich (verständlicher Weise ? ) keine Antwort. 

Die schnellste mir bekannte Antwort von Linus dauerte 4h. Er ertrinkt in
Mails. Beantwortungsquote < 10%.

>Nun ist meine Frage an euch, wie ich nun weiter vorgehen soll. Eventuell ist
>das oben geschilderte Verhalten ja so gewollt.

Das ist anzunehmen. Ein Studium der Arbeiten, die ich unter
ftp.iks-jena.de:/pub/mitarb/lutz/parsing/ liegen habe, legt die Denkweise
bei Real Time Anforderungen in ganz andere Richtungen als man sie gewohnt ist.

>allerdings bei mir zu Hause minimale Performance Vorteile (natürlich nur, wenn
>man diese Spezialfälle konstruierte, aber Linux will doch POSIXkonform sein,
>und das Verhalten der SCHED_RR-tasks ist eindeutig gegen die Spezifikationen.)

Sicher? POSIX gelesen?