Thema: CPU-Zeit-Verteilung und insbesondere Leerlauf

[tiger717]

Hallo,

mal ne Frage bzgl. Multitasking: Woher kommt die Leerlaufzeit in Windows? (Leerlaufprozess)
Tasks können ja entweder geblockt (zB. wg. IO) oder nicht geblockt (also vom Scheduler beachtet) sein. Gehe ich Reht in der Annahme, dass Leerlaufzeiten einfach entstehen, wenn alle Prozesse geblockt sind?

[jo2105]

Ich denke schon. Das ist einfach ein Pseudoprozess mit einer so niedrigen Priorität, damit er nur dann läuft, wenn kein anderer Prozess gerade bereit ist.
Man braucht ihn halt, damit das Multitasking komplett zum Stillstand kommt wenn alle "echten" Prozesse geblockt sind oder beendet wurden.

Korrigiert mich wenn ich falsch liege.

[kevin]

Genau das. Als einfachen Idle Task kann man sowas nehmen: while (true) { asm volatile("hlt"); }

[jo2105]

Jetzt wo es schon so einen schönen Thread gibt, hätte ich auch noch 2 Fragen zum Thema scheduling.

1. Was ist momentan der optimale Intervall zwischen den Taskswitches? Ich weiß nähmlich nicht wie lange moderne CPUs für einen Taskswitch brauchen (also bei einem einfachen scheduler und ohne swapping oder so).

2. Gibt es eine gute Methode um die Performance zu messen? Es bringt ja nicht, wenn ich am scheduling alogrithmus rumspiele ohne zu wissen ob sich die performance verbessert oder verschlechter.

[kevin]

Deine Fragen sind falsch.

Das Problem ist, dass du immer einen Kompromiss haben wirst. Je seltener du einen Prozess unterbrichst, um so weniger Overhead hast du und um so mehr Arbeit bekommt der aktive Task erledigt, aber um so weniger responsive wird das System als ganzes, weil Dinge länger liegen bleiben, die ein anderer Task abarbeiten müsste.

Deswegen gibt es keine Performance im Allgemeinen, die man messen könnte, sondern eine Performance bezogen auf einen bestimmten Workload. Entweder du lässt den richtigen Workload laufen und misst mit dem, oder du bastelst dir einen Benchmark, der das möglichst realistisch simuliert. Für einen OS, das für alle möglichen Zwecke geeignet sein soll (was vermutlich dein Ziel ist), müsstest du viele verschiedene Szenarien durchmessen und nach irgendwelchen Kriterien bestimmen, was dein Optimum ist. Die Zeit, die du in einem Task verbringst, könnte der Kernel messen, indem er den Timestamp beim Wechsel in den Task speichert und beim Verlassen des Tasks die Differenz auf die Gesamtlaufzeit addiert. Wenn du das mit dem PIT machst, bist du relativ ungenau, evtl. willst du dir dafür lieber die Instruktion rdtsc anschauen.

Es ist aber relativ wahrscheinlich, dass es bei deinem OS im Moment eh noch keine Rolle spielt, wie effektiv das Scheduling ist.

[Svenska]

Hallo,

zum Overhead gehört inzwischen vor allem die Cache-Benutzung. Wenn du in kurzer Zeit zwischen vielen Tasks wechselst, die viel mit Speicher hantieren, dann verlierst du jedesmal die Cache-Inhalte. Das kostet unglaublich Performance fuer die Anwendungen, wenn das ein Problem ist (ist es ziemlich schnell, weil der Cache klein ist). Dagegen ist die Zeit für einen Taskwechsel ein Witz.

Im Prinzip musst du abwägen, was dir wichtiger ist: Datendurchsatz (Arbeit pro Zeit) oder Latenz (Reaktionszeit). Was besser ist, hängt ganz konkret von deinem Anwendungsverhalten ab. Einen Königsweg gibt es leider nicht.

Es gibt auch dynamische Scheduling-Algorithmen, die Tasks klassifizieren (z.B. "interaktive Tasks" wie eine Shell möchten schnell reagieren, haben aber weniger zu tun; "Hintergrundtasks" wie z.B. Berechnungen möchten eher Durchsatz haben). Ich habe dazu mal ein paar Dinge verlinkt, u.a. den FreeBSD-Scheduler; Forensuche hilft.

Gruß,
Svenska

[jo2105]

Ich glaub ihr habt recht. ^^

Solange meine Tasks nichts anderes machen als Sinnlose Textausgaben, brauche ich meinen scheduler nicht optimieren. Da kann ich mich erstmal um wichtigere Dinge kümmern.^^

Ich habe btw gerade gemerkt, dass der scheduler bei mir gar nicht den CPU Stand in der jeweiligen Struktur speichert, sondern einfach so den nächsten Task lädt. Trotzdem hatte ich nie Probleme damit, auch Tasks die erst A ausgeben, dann solange warten, sodass sie unterbrochen werden müssen und dann B ausgeben funktionieren. Mysteriös...