Prioritäten von mehreren Prozessen (Multitasking)

R

ralli

Guest
FreeBSD als Derivat und Nachfahre von Unix ist ja ein Multitasking-Betriebssystem, d.h. mehrere Prozesse eines oder mehrerer Benutzer konkurrieren um die Vergabe der Rechenzeit mittels Scheduler des Prozessors. Wie viele andere Systeme auch, arbeitet Unix nach dem Zeitscheiben-Prinzip. Kann mir bitte mal jemand von den technisch versierten Usern erklären, wie das funktioniert? Wenn ich browse, einen Film rendere und gleichzeitig eine Datensicherung starte, welcher Prozess bekommt denn dann die höchste Priorität? Nach welchen Kriterien wird denn da vorgegangen? Das hat mich immer schon mal interessiert.
 
Es ist sehr schwierig die interaktiven Prozesse zu erkennen deswegen geht der Kernel ersmal davon aus das jeder Prozess halbwegs interaktiv ist und "bestraft" Prozesse die erwiesenermaßen nicht interaktiv ist. Ein UNIX Kernel implementiert meistens präemptives Multitasking d.h. wenn ein Prozess die CPU nicht freiwillig abgibt kommt nach nen paar Millisekunden nen Timerinterrupt und löst den Scheduler aus ohne das der gerade laufende Prozess daran etwas ändern kann oder mitwirken muss. Der Scheduler kann jetzt Prozesse die widerholt ihre zur verfügbare CPU-Zeit vollständig ausgenutzt haben "bestrafen" und ihre Priorität reduzieren sowie die von Prozessen die früher die CPU aufgeben und auf I/O blockieren erhöhen. Das ist natürlich stark vereinfacht. Ich hoffe es hilft dir dennoch eine grobe Vorstellung dafür zu bekommen wie der Kernel interaktive Prozesse bevorzugen kann.
 
Danke @Crest, das hilft mir schon, es etwas besser zu verstehen. Ich habe natürlich recherchiert, auch Wikipedia bemüht, aber es sind halt noch Fragen offen geblieben. Ein Beispiel: Kann ich die Priorität und damit die Wichtigkeit eines Prozesses auch als User selbst bestimmen? Habe nichts darüber gefunden.
 
Dafür müsste man noch etwas mehr in die Tiefe gehen. Mein Professor sagte einmal den schönen Satz "Scheduling kann man nur falsch machen". Denn es ist völlig egal, welche Strategie man beim Berechnen der Prozess-Prioritäten anwendet, es lässt sich immer ein Workload finden, für den sie nachteilig ist. FreeBSD bietet zwei Scheduler an, sie auszutauschen geht allerdings nur durch einen Neubau des Kernels:
  • SCHED_4BSD ist eine Implementierung eines ursprünglich mit 4.4BSD eingeführten, vergleichsweise simplen Algorithmus. Er legt alle Threads in eine globale Run Queue, berechnet ihre Prioritäten anhand einiger Werte wie z.B. CPU-Zeit Konsum in der Vergangenheit und sobald ein Slot frei wird, wirft er den Prozess mit der jeweils höchsten Priorität hinein. Es gibt durchaus Szenarien, wo ein so simpler Ansatz ausreichend oder optimal ist, oft ist die Welt dafür inzwischen aber zu kompliziert.
  • SCHED_ULE ist seit sicher 10 Jahren der Standard-Scheduler. Er implementiert einen recht komplizierten Algorithmus, der Anhand diverser verschiedener Werte von CPU-Zeit Konsum in der Vergangenheit, konsumierten Kernel-Locks, derzeitiges Interrupt-Aufkommen und so weiter Prioritäten berechnet. Die Threads werden Anhand der Prioritäten in verschiedene Klassen eingeteilt, die Threads einer Klasse auf eine oder mehrere Run Queues verteilt. Wird ein Slot frei, entscheidet der Scheduler unter Einbeziehung der CPU- und Speicher-Topologie, wieder dem Interrupt-Aufkommen und einigen Dingen, welche Run Queue bearbeitet wird. Der Thread in der jeweiligen Run Queue, der am längsten nicht gelaufen ist, gewinnt.
Während SCHED_4BSD mit nice(1) gesetzte Prioritäten dankend annimmt, ignoriert SCHED_ULE sie weitgehend. Sie fließen zwar mit ein, ihre Auswirkungen sind aber gering. Dafür misst SCHED_ULE Realtime Priorities (mit rtprio(1) zu setzen) eine sehr hohe Bedeutung ein. Bis zu dem Punkt, dass er sich selbst den Hahn zudreht und das System in einen Deadlock gerät.

Zu dem ganzen Thema Prozesse, Threads und ihre Verwaltung findet sich ein sehr tiefgehendes Kapitel in "Design and Implementation of the FreeBSD Operating System" von Kirk McKusick et. al., vor etwa zwei Jahren in der zweiten, grundüberarbeiteten Auflage erschienen. Ein Teil des Kapitels ist im Preview zugänglich: http://www.informit.com/articles/article.aspx?p=2249436&seqNum=4
 
Also. das präemptives Multitasking ein sehr komplexes Thema ist, ist mir schon klar gewesen. Die Arbeitsteilung, die vorgenommen wird, ist nach meinem simplen technischen Vorstellungsvermögen dann doch um einiges effektiver wie vor einigen Jahren, dank der neueren Prozessorgenerationen mit Mehrkern CPU's. Früher bei Pentium CPU's war das wohl doch etwas ganz anderes, weil der Prozessor nur einen einzigen Kern hatte. Heute kann die Last wohl besser verteilt werden. Bitte sofort intervenieren, wenn ich etwas falsch einordne oder falsch verstanden habe. Die Manpage zu nice werde ich mir durchlesen und den Artikel von Kirk McKusick auch, danke.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben