Betriebssysteme

Betriebssysteme

Coverbild:

Dieser für den Lehrstuhl sehr zentrale Forschungsbereich beschäftigt sich mit Konzepten und Techniken zur gezielten Zuordnung von Rechenressourcen zu den darum konkurrierenden Prozessen und der damit verbundenen Steuerung der Ausführung der jeweiligen Maschinenprogramme. Dabei werden nicht nur analytische Verfahren betrachtet, sondern vor allem auch konstruktive Ansätze verfolgt. Betrachtet werden maßgeschneiderte Betriebssystemstrukturen entsprechend den Erfordernissen einer jeweiligen Anwendungsdomäne, sowohl als Eigenentwicklung von Grund auf neu oder als Erweiterung beziehungsweise Anpassung bereits bestehender Lösungen. In funktionaler wie auch nicht-funktionaler Hinsicht ist die Herangehensweise einerseits anwendungsorientiert und andererseits hardwarezentrisch. Die Arbeiten sind vor allem geprägt durch die Technologie mehr- oder vielkerniger Prozessoren und den damit verbundenen Herausforderungen in der Koordinierung von Kommunikation und Konkurrenz paralleler Prozesse.

Projekte:

Dynamische Betriebssystemspezialisierung

(Drittmittelfinanzierte Einzelförderung)

Projektleitung: ,
Projektbeteiligte: , , ,
Projektstart: 1. Mai 2022
Akronym: DOSS
Mittelgeber: DFG-Einzelförderung / Sachbeihilfe (EIN-SBH)
URL: https://sys.cs.fau.de/research/doss

Abstract:

Ein Betriebssystem befindet sich zwischen zwei Fronten: Einerseits ("oben") die Maschinenprogramme der Anwendungen mit ihren teils sehr unterschiedlichen funktionalen und nichtfunktionalen Anforderungen und andererseits ("unten") die Rechnerhardware, deren Merkmale und Gerätschaften den Anwendungen idealerweise "ungefiltert" und "geräuschfrei" zur Verfügung gestellt werden sollen. Allerdings kann ein Allzwecksystem in keiner seiner Funktionen so effizient sein wie ein System, das speziell für einen bestimmten Zweck entwickelt wurde und weniger anspruchsvolle Anwendungen dürfen verlangen, dass sie nicht gezwungen werden, für die verbrauchten Ressourcen durch die nicht benötigten Funktionen zu zahlen. So ist es nicht ungewöhnlich, dass große Systeme, einmal in Betrieb genommen, in der Regel häufigen Änderungen unterliegen --- eben gerade auch deshalb, um eine höhere Passgenauigkeit an sich ändernde Anwendungsanforderungen zu erreichen.

Das ideale Betriebssystem bietet genau das, was für die jeweilige Anwendung benötigt wird --- nicht mehr und nicht weniger, aber eben auch in Abhängigkeit von den Merkmalen der Hardwareplattform. Ein solches Ideal ist jedoch, wenn überhaupt, nur für den Einprogrammbetrieb realistisch. Bei Mehrprogrammbetrieb müssten die verschiedenen Anwendungen schon "hinreichend gleiche" funktionale und nichtfunktionale Anforderungsmerkmale aufweisen, um keine der Anwendungen mit den Gemeinkosten (overhead) zu belasten, die die nicht benötigten Funktionen mit sich bringen. Ein Betriebssystem mit diesen Eigenschaften fällt in die Kategorie Spezialsystem (special purpose operating system), es ist zugeschnitten auf die Bedürfnisse von Anwendungen eines bestimmten Typs.

Im Gegensatz dazu steht das Allzwecksystem (general purpose operating system), wo letztlich nur zu hoffen ist, dass eine Anwendung nicht mit zu hohen Gemeinkosten durch die nicht benötigten Funktionen belastet wird. Hier kann immerhin versucht werden, das "Hintergrundrauschen" (background noise) im Betriebssystem bei Bedarf zu minimieren --- idealerweise in diesem Fall mit unterschiedlichem "Rabatt" je nach Programmtyp. Das Betriebssystem müsste dann mit weniger anspruchsvollen Anwendungen nicht nur dynamisch von unnötigem Ballast befreit werden und schrumpfen können, sondern auch in die Lage versetzt werden, bei anspruchsvolleren Anwendungen mit dafür nötigen und zusätzlichen Funktionen wieder anzuwachsen. Spezialisierung eines Betriebssystems in Abhängigkeit vom jeweiligen Anwendungsfall bedeutet letztlich funktionelle Abmagerung und Anreicherung, wozu ein geeigneter Systemsoftwareentwurf zwar wünschenswert ist, sich aber gerade bei Altsoftware (legacy system) oft nicht mehr umsetzen lässt.

Ein Umstand für die Spezialisierung eines Betriebssystems bezieht sich auf explizit "von außen her" initiierte Maßnahmen. Dies betrifft einerseits ausgewählte Systemaufrufe und andererseits Vorgänge wie das Urladen (bootstrap) sowie das Laden von Maschinenprogrammen, Betriebssystemkernmoduln oder von Programmen, die in sandkastenartigen virtuellen Maschinen innerhalb des Betriebssystemkerns zur Ausführung kommen sollen. Diese Form der Spezialisierung ermöglicht ebenfalls die dynamische Generierung von gezielten Schutzmaßnahmen in Folge von besonders vulnerablen Betriebssystemoperationen, wie dem Laden von externen Modulen des Betriebssystemkerns. Der andere ausschlaggebende Umstand für die Spezialisierung eines Betriebssystems bezieht sich auf implizit "von innen heraus" initiierte Maßnahmen. Dies betrifft mögliche Reaktionen eines Betriebssystems auf erst zur Laufzeit wahrnehmbare Änderungen im eigenen Laufzeitverhalten, um daraufhin etwa die Strategien einer Ressourcenverwaltung der jeweiligen Arbeitslast anzupassen und entsprechende Systemsoftware in das bestehende System nahtlos einzupassen.

Projektfokus ist die dynamische Betriebssystemspezialisierung, ausgelöst durch extrinsische und intrinsische Ereignisse. Im Vordergrund stehen Verfahren und Techniken, die (a) unabhängig von einem bestimmten Programmierparadigma oder Hardwareansatz sind und (b) auf bedarfssynchrone (just in time, JIT) Übersetzung von Teilen des Betriebssystem(kern)s basieren, um im bereits laufenden Betrieb bedarfsweise (on demand) zu ladende oder vorausschauend (anticipatory) zu ersetzende Betriebssystemprogramme den jeweiligen Gegebenheiten an den "Betriebssystemfronten" anzupassen. Untersuchungsgegenstand sind bestehende Allzwecksysteme wie etwa Linux.

Publikationen:

Nichtflüchtigkeit in energiebewussten Betriebssystemen

(Drittmittelfinanzierte Einzelförderung)

Projektleitung: ,
Projektstart: 1. Januar 2022
Akronym: NEON
Mittelgeber: DFG-Einzelförderung / Sachbeihilfe (EIN-SBH)
URL: https://sys.cs.fau.de/en/research/neon-note

Abstract:

Der gegenwärtige Trend hin zu schnellem, byteadressierbarem nichtflüchtigem Hauptspeicher (non-volatile memory, NVM) mit Latenzen und einer Schreibfestigkeit näher an SRAM und DRAM als an Flash positioniert NVM als möglichen Ersatz für die etablierten flüchtigen Technologien. Während einerseits die Nichtflüchtigkeit und geringe Leckleistung NVM, neben weiteren vorteilhaften Merkmalen, zum attraktiven Kandidaten für neue Systementwürfe macht, ergeben sich andererseits auch große Herausforderungen insbesondere für die Programmierung solcher Systeme. So bewirken etwa Stromausfälle in Kombination mit NVM zum Schutz des Rechenzustands Kontrollflüsse, die einen sequentiellen Prozess unerwartet in einen nichtsequentiellen Prozess verwandeln können: Ein Programm muss sich mit seinem eigenen Zustand aus früheren unterbrochenen Läufen auseinandersetzen.

Wenn Programme direkt im NVM zur Ausführung kommen können, wird normaler flüchtiger Hauptspeicher (funktional) überflüssig. Flüchtiger Speicher findet sich dann ausschließlich im Cache und in Geräte-/Prozessoregistern ("NVM-pure"). Ein darauf ausgelegtes Betriebssystem kann auf viele, wenn nicht sämtliche, für gewöhnlich sonst zu realisierende Persistenzmaßnahmen verzichten und dadurch sein Maß an Hintergrundrauschen (background noise) verringern. Im Einzelnen betrachtet lassen sich so der Energiebedarf senken, die Rechenleistung erhöhen und Latenzen verringern. Des Weiteren ist durch den Wegfall oder Vereinfachung dieser Persistenzmaßnahmen ein "NVM-pure" Betriebssystem schlanker als sein funktional identischer Zwilling herkömmlicher Bauart. Dies trägt einerseits zur besseren Analysierbarkeit nichtfunktionaler Eigenschaften des Betriebssystems bei und ergibt andererseits eine kleinere Angriffsoberfläche beziehungsweise vertrauenswürdige Rechenbasis.

Das Projekt verfolgt einen "NVM-pure" Ansatz. Dabei resultiert ein drohender Stromausfall in einer Unterbrechungsanforderung (power- failure interrupt, PFI), mit der Folge, einen Fixpunkt (checkpoint) des unvermeidbaren volatilen Systemzustands zu erstellen. Zusätzlich werden, um mögliche PFI-Verluste zu tolerieren, sensitive Betriebssystemdatenstrukturen in transaktionaler Weise analog zu Methoden der nichtblockierenden Synchronisation abgesichert. Des Weiteren werden Methoden der statischen Programmanalyse genutzt, um (1) das Betriebssystem von überflüssigen Persistenzmaßnahmen, die sonst nur noch Hintergrundrauschen erzeugen, zu entschlacken, (2) ununterbrechbare Anweisungsfolgen mit zu hohen Unterbrechungslatenzen, die die PFI-basierte Fixpunktsicherung scheitern lassen können, aufzubrechen und (3) die Arbeitsbereiche der dynamischen Analyse des Energiebedarfs zu definieren. Zur Demonstration, dass ein "NVM-pure" Betriebssystem gegenüber seinem funktional gleichen herkömmlichen Zwilling sowohl in zeitlichen als auch energetischen Belangen effizienter operieren kann, laufen die Arbeiten beispielhaft mit Linux.

Publikationen:

Stromausfallbewusster byteadressierbarer virtueller nichtflüchtiger Speicher (PAVE)

(Drittmittelfinanzierte Gruppenförderung – Teilprojekt)

Titel des Gesamtprojektes: SPP 2377: Disruptive Memory Technologies
Projektleitung: ,
Projektstart: 5. April 2021
Projektende: 14. Mai 2026
Akronym: PAVE
Mittelgeber: DFG / Schwerpunktprogramm (SPP)
URL: https://sys.cs.fau.de/en/research/pave-note

Abstract:

Subsysteme für virtuellen Speicher (VM) lassen die Unterschiede zwischen Sekundär- und Hauptspeicher verschwimmen, so dass auf flüchtige und nicht-flüchtige Daten gleichermaßen mit denselben CPU-Instruktionen zugegriffen werden kann. Jedes VM-Subsystem versucht, häufig benötigte Daten in schnellem, flüchtigen Hauptspeicher zu halten, um die hohe Zugriffslatenz des Sekundärspeichers zu vermeiden, unabhängig davon, ob die Daten selbst flüchtig sind oder nicht. Das Aufkommen von byte- adressierbarem NVRAM ändert dieses Muster nicht grundlegend, da diese Technologie aufgrund der höheren Zugriffslatenz derzeit weder DRAM als schnellen Hauptspeicher, noch herkömmlichen Sekundärspeicher aufgrund der höheren Kosten und geringeren Kapazität, ersetzen kann. Daher sollten VM-Subsysteme NVRAM- gewahr gemacht und so erweitert werden, dass alle verfügbaren byte- adressierbaren Speichertechnologien gemäß ihrer jeweiligen Stärken eingesetzt werden können. Mit Hilfe einer in der virtuellen Speicherverwaltung des Betriebssystems verankerten Abstraktion lässt sich erreichen, dass bestehende Software ohne weitere Änderung von NVRAM profitieren kann. Dadurch, dass VM- Subsysteme hochkomplexe und fein abgestimmte Softwaresysteme sind, die teils seit Jahrzehnten immer weiter entwickelt werden, folgen wir einem minimal-invasivem Ansatz, um NVRAM-Unterstützung in ein bereits existierendes VM-Subsystem zu integrieren, anstatt eines von Grund auf neu zu entwickeln. NVRAM soll als unmittelbarer DRAM-Ersatz bei Speicherknappheit dienen, um Prozesse mit großem Speicherbedarf auch bei Ressourcenknappheit lauffähig zu halten. Jedoch müssen aufgrund der höheren NVRAM-Zugriffslatenz auch nicht-flüchtige Daten zeitweise im schnellen, aber flüchtigen DRAM oder in Prozessorcaches bewahrt werden. Unser neues VM- Subsystem - wir passen FreeBSD entsprechend an - ermöglicht deshalb die Wanderung von Seiten zwischen DRAM und NVRAM, sofern es die verfügbaren Ressourcen erlauben. Somit wird DRAM gewissermaßen als ein großer, durch Software verwalteter, flüchtiger Cache für NVRAM genutzt. Daraus ergibt sich in der Folge das Problem von möglichem Datenverlust im Falle eines Stromausfalls. Das VM-Subsystem muss daher seine eigenen Metadaten in einem konsistenten und wiederherstellbaren Zustand halten und in einem solchen Fall modifizierte Seiten aus dem DRAM im NVRAM persistieren, um Datenverluste zu vermeiden. Ersteres erfordert einen hochgradig effizienten transaktionalen Mechanismus zur Veränderungen von komplexen und parallel genutzen Datenstrukturen, die für die VM-Metadaten zum Einsatz kommen. Letzteres hingegen bedeutet, dass unter Umständen große Mengen an modifizierten Seiten mit einem eng begrenzten Restenergie- und Zeitfenster gesichert werden müssen.

Publikationen:

Robuste, stromsparende eingebettete Datenübertragungsstationen

(Drittmittelfinanzierte Gruppenförderung – Teilprojekt)

Titel des Gesamtprojektes: SPP 2378 Resilient Worlds
Projektleitung: ,
Projektbeteiligte: , ,
Projektstart: 26. März 2021
Akronym: SPP 2378 ResPECT
Mittelgeber: Deutsche Forschungsgemeinschaft (DFG)

Abstract:

Innerhalb des sehr weiten Feldes der Resilienz vernetzter Welten konzentriert sich ResPECT auf einen Kernbaustein aller vernetzten Systeme: Sensor- oder Aktor-Knoten in cyber-physischen Systemen. Bis heute wird die Kommunikation als Zusatzfunktionalität eingebetteter Systeme verstanden. Das System an sich wird Störungs-tolerant ausgelegt und kann mit Stromausfällen umgehen oder sogar Hardwareprobleme in gewissem Maße kompensieren. Die Kommunikation jedoch wird in die Konzeption nicht einbezogen, sondern kann die Verlässlichkeit allenfalls nutzen. ResPECT entwickelt daher ein holistisches Betriebssystem- und Kommunikations-Protokoll-Konzept, welches davon ausgeht, dass die Vermittlung von Information (der Erhalt von Steuerdaten für Aktoren oder das Versenden von Sensordaten) die Kernaufgabe fast aller vernetzten Knoten ist. Damit muss diese Aufgabe Teil des Managements des Betriebssystems werden. Grundlage von ResPECT sind zwei Pfeiler: Nicht-flüchtiger Speicher und transaktionaler Betrieb. Nicht-flüchtiger Speicher hat sich in den letzten Jahren zu einem sehr ernst zu nehmenden Element der Speicherhierarchie entwickelt. Selbst eingebettete Plattformen mit ausschließlich nicht-flüchtigem Speicher werden vorstellbar. Netzwerkkommunikation ist, anders als soziale Kommunikation, im Kern transaktional: Daten werden gesammelt und unter Rahmenbedingungen wie Latenz, Fehlertoleranz und Energieverbrauch der Übertragung sowie Alter und damit Wert der zu übertragenden Information vermittelt. Anders als das Betriebssystem unterliegt die Kommunikation jedoch einer Vielzahl äußerer Einflüsse und Störungen. Auch die Dauer einer Störung hat unmittelbaren Einfluss auf z. B. den Erhalt der physischen Verbindung und muss bei Wiederaufnahme berücksichtigt werden. ResPECT wird daher - durch die Zusammenarbeit von Betriebssystem- und Kommunikationsexperten - ein auf Transaktionen basierendes Modell für das Betriebssystem sowie die Kommunikation entwickeln und durch den Einsatz nicht-flüchtiger Speicher dafür Sorge tragen, dass Zustände im Ablauf der Transaktionen zu jedem Zeitpunkt bekannt sind und persistent gespeichert werden. Dieses Beobachten und Speichern muss sehr effizient (sowohl in Bezug auf den Energieverbrauch als auch in Bezug auf die im nicht-flüchtigen Speicher zu speichernden Datenmengen) geschehen und daher als Kernaufgabe des Betriebssystems implementiert werden. Um die Verallgemeinerbarkeit sicher zu stellen und das Modell für viele zukünftige Plattformen nutzbar zu machen, wird sich ResPECT auf IP-Netze fokussieren und Kommunikationsnetze verwenden, welche üblicherweise als WAN, LAN oder PAN (Wide, Local oder Personal Area Network) betrieben werden.

Publikationen:

Migrationsgewahre Laufzeitumgebung für Echtzeit- Mehrkernsysteme

(Projekt aus Eigenmitteln)

Projektleitung:
Projektbeteiligte:
Projektstart: 11. August 2020
Akronym: maRE

Abstract:

Das Vorhaben entwickelt ein neuartiges Paradigma, um Prozessmigration in Mehrkern-Echtzeitsystemen zeitlich vorhersagbar zu gestalten. Kern des Ansatzes ist das Konzept der migrationsgewahren Laufzeitumgebung (migration-aware real-time executive), in welcher Migrationsentscheidungen anstatt auf globalen Lastparametern systematisch auf Grundlage von Hinweisen der unter (strikten) Echtzeitbedingungen ablaufenden Maschinenprogramme der Anwendungsebene getroffen werden. Diese sogenannten Migrationshinweise (migration hints) betreffen zeitliche und räumliche Aspekte von Echtzeitprozessen, sie markieren potentielle Migrationspunkte in dem betreffenden nichtsequentiellen (mehrfädigen) Maschinenprogramm. Sie befähigen das Betriebssystem Entscheidungen zu treffen, die sich möglichst günstig auf die Vorhersagbarkeit und Leistungsfähigkeit des Gesamtsystems auswirken. Konkret nimmt das Vorhaben an, dass anwendungsspezifische Hinweise auf zulässige und besonders günstige Programmpunkte für die Migration eine aufwandsarme Möglichkeit darstellen, um bestehende Echtzeitsysteme und Techniken hinsichtlich Antwortzeit und Planbarkeit zu verbessern. Den Untersuchungsgegenstand stellen Mehrkern-Plattformen mit heterogenen Speicherarchitekturen dar. Im Fokus stehen die durch Migration verursachten Verwaltungsgemeinkosten, welche von Speicherort und Umfang der Migrationsdaten abhängig sind. Diese über die Ausführungszeit variierenden Kosten werden werkzeuggestützt durch Methoden der statischen Analyse zur Entwurfszeit ermittelt und zur Identifikation von Migrationspunkten mit gut vorhersagbaren Kosten genutzt. Ausgehend von existierenden Echtzeitbetriebssystemen entwickelt das Vorhaben migrationsgewahre Varianten, welche das Wissen über diese günstigen Migrationspunkte durch speziell angepasste Schnittstellen und automatisch präparierte Anwendungsprogramme in Form von Migrationshinweisen zur Verfügung gestellt bekommen, um somit zur Laufzeit möglichst positive Entscheidungen für das Gesamtsystem treffen zu können.

Kontaktpersonen:

Beteiligte Wissenschaftler:

Publikationen: