Lowlevel
Lowlevel => OS-Design => Thema gestartet von: micha am 25. October 2012, 11:29
-
Mir kam jetzt mal eine Idee, dass man die Frequenz, mit der der Timerinterrupt und dann der Scheduler ausgelöst wird dynamisch nach der Anzahl der aktiven Prozesse optimal einstellt. Wenn ich den PIT beim Initialisieren auf 50Hz stelle und nur ein oder zwei Prozesse laufen, wird ja ständig der Interrupt ausgelöst. Bei Zwei Prozessen muss die Frequenz aber gar nicht so hoch sein. Deshalb könnte man ja die Frequenz nach der Anzahl der aktiven Tasks richten.
Lohnt es sich die PIT-Frequenz immer zu ändern?
-
Kannst du damit überhaupt noch einigermaßen zuverlässig die Zeit halten? Der Timer wird ja nicht nur benutzt, um den Scheduler aufzurufen, sondern auch für die aktuelle Systemzeit.
Die grundsätzliche Idee, einen Timer so einzustellen, dass er erst dann triggert, wenn es tatsächlich etwas zu tun gibt, ist natürlich sinnvoll und beispielsweise Linux macht das heutzutage normalerweise (Stichwort "tickless kernel"). Aber ich glaube, das ist dann ein zusätzlicher Timer, der sich nicht auf die Systemzeit auswirkt.
Ich glaube allerdings, dass die Vorteile bei deinem aktuellen Entwicklungsstand noch keine Rolle spielen und du nur viel Aufwand für wenig Nutzen hättest.
-
Kannst du damit überhaupt noch einigermaßen zuverlässig die Zeit halten? Der Timer wird ja nicht nur benutzt, um den Scheduler aufzurufen, sondern auch für die aktuelle Systemzeit.
Der CMOS RTC hat doch den IRQ 8. Den kann man ja auch als Timer verwenden.
-
Die RTC ist m.W. ungenauer als ein mit fixer Frequenz getakteter Timer, sonst würde man die Systemzeit nicht mit dem Timer halten.
-
Naja http://www.lowlevel.eu/wiki/Scheduler#Round Robin
Jeder Prozess wird nach einer festen Zeit gestoppt und der nächste gestartet
Man könnte hier z.B eine Zeit festsetzen nach der der Scheduler einmal zu allen Task gewechselt haben sollte und teilen diese durch die Taskzahl. Damit würde die Timerfrequenz nicht geändert sondern nur die Anzahl der Taskswitchs und es könnte trotzdem zu positiven Performance Auswirkungen führen.
-
Damit erreichst du, dass eine steigende Prozessanzahl die gesamte für Prozesse verfügbare CPU-Zeit reduziert, weil du immer häufiger die Prozesse wechseln musst. Kontextwechsel sind sehr teuer. Du verringerst damit den Datendurchsatz, verbesserst aber die maximale Latenz auf deine Zykluszeit (zumindest solange, bis dein System zusammenbricht).
Ist für Echtzeitsysteme praktisch und läuft dort auf einen Algorithmus ähnlich Rate Monotonic hinaus.