diff --git a/Advanced Operating Systems.md b/Advanced Operating Systems.md index 1272b7a..6330c6e 100644 --- a/Advanced Operating Systems.md +++ b/Advanced Operating Systems.md @@ -47,7 +47,7 @@ Gegenstand dieser Vorlesung: Konstruktionsrichtlinien für solche ,,High-End Bet - Quality ofservice(QoS) requirements - u.a. - ,,~ilities'' - - im Englischen:nichtfunktionale Eigenschaften eines Systems etc. informell auch als seine „ilities“ bezeichnet, hergeleitet von Begriffen wie + - im Englischen: nichtfunktionale Eigenschaften eines Systems etc. informell auch als seine „ilities“ bezeichnet, hergeleitet von Begriffen wie - Stability - Portability - ... @@ -153,6 +153,485 @@ Diskussion jeder Eigenschaft: (Bsp.: Echtzeitfähigkeit) # Sparsamkeit und Effizienz +## Motivation +Sparsamkeit (Arbeitsdefinition): Die Eigenschaft eines Systems, seine Funktion mit minimalem Ressourcenverbrauchauszuüben. + +Hintergrund: sparsamer Umgang mit einem oder mehreren Ressourcentypen = präziser: Effizienz bei Nutzung dieser Ressourcen + +Effizienz: Der Grad, zu welchem ein System oder eine seiner Komponenten seine Funktion mit minimalem Ressourcenverbrauch ausübt. (IEEE) + +Entwurfsentscheidungen für BS: +1. Wie muss bestimmter Ressourcentyp verwaltet werden, um Einsparungen zu erzielen? +2. Welche Erweiterungen/Modifikationen des Betriebssystems (z.B. neue Funktionen, Komponenten, ...) sind hierfür notwendig? + +Konkretisierung: Ressource, welche sparsam verwendet wird. + +Beispiele: +- mobile Geräte: Sparsamkeit mit Energie +- kleine Geräte, eingebettete Systeme: + - Sparsamkeit mit weiteren Ressourcen, z.B. Speicherplatz + - Betriebssystem (Kernel + User Space): geringer Speicherbedarf + - optimale Speicherverwaltung durch Betriebssystem zur Laufzeit +- Hardwareoptimierungen im Sinne der Sparsamkeit: + - Baugrößenoptimierung(Platinen-und Peripheriegerätegröße) + - Kostenoptimierung(kleine Caches, keine MMU, ...) + - massiv reduzierte HW-Schnittstellen (E/A-Geräte, Peripherie, Netzwerk) + +Mobile und eingebettete Systeme (eine kleine Auswahl) +- mobile Rechner-Endgeräte + - Smartphone, Smartwatch + - Laptop-/Tablet-PC +- Weltraumfahrt und -erkundung +- Automobile + - Steuerung von Motor-und Bremssystemen + - Fahrsicherheit + - Insasseninformation (und –unterhaltung) + - (teil-) autonomes Fahren +- verteilte Sensornetze (WSN) +- Chipkarten +- Multimedia-und Unterhaltungselektronik + - eBookReader + - Spielkonsolen + - Digitalkameras + +Beispiel: Weltraumerkundung +- Cassini-Huygens (1997–2017) + - Radionuklidbatterien statt Solarzellen + - Massenspeicher: SSDs statt Magnetbänder +- Rosetta (2004–2016) + - 31 Monate im Energiesparmodus +- Opportunity (2003–2019) + - geplante Missionsdauer: 90 d + - Missionsdauer insgesamt: >> 5000 d +- Hayabusa (2003–2010) + - Beschädigung der Energieversorgung + - Energiesparmodus: um 3 Jahre verzögerte Rückkehr +- Voyager 1 (1977 bis heute) + - erste Flugphase: periodisch 20 Monate Standby, 20 Stunden Messungen + - liefert seit 40 Jahren Daten + +## Energieeffizienz +Hardwaremaßnahmen +- zeitweiliges Abschalten/Herunterschalten momentan nicht benötigter +Ressourcen, wie +1. Laufwerke: CD/DVD, ..., Festplatte +2. Hauptspeicherelemente +3. (integrierte/externe) Peripherie: Monitor, E/A-Geräte, ... + +Betriebssystemmechanismen +1. Dateisystem-E/A:energieeffizientes Festplatten-Prefetching(2.2.1) +2. CPU-Scheduling: energieeffizientes Scheduling(2.2.2) +3. Speicherverwaltung:minimale Leistungsaufnahme durchSpeicherzugriffe mittels Lokalitätsoptimierung [DGMB07] +4. Netzwerk:energiebewusstes Routing +5. Verteiltes Rechnen auf Multicore-Prozessoren: temperaturabhängige Lastverteilung +6. ... + +### Energieeffiziente Dateizugriffe +Hardwarebedingungen: Magnetplatten (HDD), Netzwerkgeräte, DRAM-ICs,... sparen nur bei relativ langen Inaktivitätsintervallen Energie. + +- Aufgabe: Erzeugen kurzer, intensiver Zugriffsmuster $\rightarrow$ lange Inaktivitätsintervalle (für alle Geräte mit geringem Energieverbrauch im Ruhezustand) +- Beobachtung bei HDD-Geräten: i.A. vier Zustände mit absteigendem Energieverbrauch: + 1. Aktiv: einziger Arbeitszustand + 2. Idle (Leerlauf): Platte rotiert, aber Plattenelektronik teilweise abgeschaltet + 3. Standby: Rotation abgeschaltet + 4. Sleep: gesamte restliche Elektronik abgeschaltet +- ähnliche, noch stärker differenzierte Zustände bei DRAM (vgl. [DGMB07] ) + +Energiezustände beim Betrieb von Festplatten: +- ![](Assets/AdvancedOperatingSystems-energiezustände-festplatte.png) +- Schlussfolgerung: durch geringe Verlängerungen des idle - Intervalls kann signifikant der Energieverbrauch reduziert werden. + +#### Prefetching-Mechanismus +- Prefetching („Speichervorgriff“, vorausschauendes Lesen) & Caching + - Standard-Praxis bei moderner Datei-E/A + - Voraussetzung: Vorwissen über benötigte Folge von zukünftigen Datenblockreferenzen (z.B. Blockadressen für bestimmte Dateien, gewonnen durch Aufzeichnung früherer Zugriffsmuster beim Start von Anwendungen -Linux: readahead syscall) + - Ziel: Performanzverbesserungdurch Durchsatzerhöhung u. Latenzzeit-Verringerung + - Idee: Vorziehen möglichst vieler E/A-Anforderungen an Festplatte + zeitlich gleichmäßige Verteilung der verbleibenden + - Umsetzung: Caching (Zwischenspeichern) dieser vorausschauend gelesenen Blöcke in ungenutzten Hauptspeicherseitenrahmen ( pagecache ) +- Folge: Inaktivitätsintervalle überwiegend sehr kurz $\rightarrow$ Energieeffizienz ...? +- Zugriffsoperation: (durch Anwendung) + - access(x) ... greife (lesend/schreibend) auf den Inhalt von Festplattenblock x im Page Cache zu +- Festplattenoperationen: + - fetch(x) ... hole Block x nach einem access(x) von Festplatte + - prefetch(x) ... hole Block x ohne access(x) von Festplatte + - beide Operationen schreiben x in einen freien Platz des Festplattencaches; falls dieser voll ist ersetzen sie einen der Einträge gemäß fester Regeln $\rightarrow$ Teil der (Pre-) Fetching-Strategie +- Beispiel für solche Strategien: Anwendung ... + - mit Datenblock-Referenzstrom A, B, C, D, E, F, G, ... + - mit konstanter Zugriffsdauer: 10 Zeiteinheiten je Blockzugriff + - Cache-Kapazität: 3 Datenblöcke + - Zeit zum Holen eines Blocks bei Cache-Miss: 1 Zeiteinheit +- Beispiel: Traditionelles Prefetching + - Fetch-on-demand-Strategie (kein vorausschauendes Lesen) + - Strategie entsprechend Prefetching- Regeln nach Cao et al. [CFKL95] (= traditionelle Disk-Prefetching- Strategie) + - traditionelle Prefetching-Strategie: bestimmt + - wann ein Datenblock von der Platte zu holen ist (HW-Zustand aktiv ) + - welcher Block zu holen ist + - welcher Block zu ersetzen ist + - Regeln für diese Strategie: + 1. Optimales Prefetching: Jedes _prefetch_ sollte den nächsten Block im Referenzstrom in den Cache bringen, der noch nicht dort ist. + 2. Optimales Ersetzen: Bei jedem ersetzenden _prefetch_ sollte der Block überschrieben werden, der am spätesten in der Zukunft wieder benötigt wird. + 3. „Richte keinen Schaden an“: Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird. + 4. Erste Möglichkeit: Führe nie ein ersetzendes _prefetch_ aus, wenn dieses schon vorher hätte ausgeführt werden können. +- Energieeffizientes Prefetching + - Optimale Ersetzungsstrategie und 3 unterschiedliche Prefetching-Strategien: + - Fetch-on-demand-Strategie: + - Laufzeit: 66 ZE für access(A) ... access(F) , 7 Cache-Misses + - Disk-Idle-Zeit: 6 Intervalle zu je 10 ZE + - Strategie entsprechend Prefetching-Regeln [CFKL95] (traditionelle Disk-Prefetching-Strategie): + - Laufzeit: 61 ZE für access(A) ... access(F) , 1 Cache-Miss + - Disk-Idle-Zeit: 5 Intervalle zu je 9 ZE und 1 Intervall zu 8 ZE (= 53 ZE) + - Energieeffiziente Prefetching-Strategie, die versucht Länge der Disk-Idle-Intervalle zu maximieren: + - gleiche Laufzeit und gleiche Anzahl Cache-Misses wie traditionelles Prefetching + - Disk-Idle-Zeit: 2 Intervalle zu 27 bzw. 28 ZE (= 55 ZE) +- Auswertung: Regeln für energieeffiziente Prefetching-Strategie nach Papathanasiou elal.: [PaSc04] + 1. Optimales Prefetching: Jedes _prefetch_ sollte den nächsten Block im Referenzstrom in den Cache bringen, der noch nicht dort ist. + 2. Optimales Ersetzen: Bei jedem ersetzenden _prefetch_ sollte der Block überschrieben werden, der am spätesten in der Zukunft wieder benötigt wird. + 3. „Richte keinen Schaden an“: Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird. + 4. Maximiere Zugriffsfolgen: Führe immer dann nach einem _fetch_ oder _prefetch_ ein weiteres _prefetch_ aus, wenn Blöcke für eine Ersetzung geeignet sind. (i.S.v. Regel 3) + 5. Beachte Idle-Zeiten: Unterbrich nur dann eine Inaktivitätsperiode durch ein _prefetch_ , falls dieses sofort ausgeführt werden muss, um einen Cache-Miss zu vermeiden. + +Allgemeine Schlussfolgerungen +1. Hardware-Spezifikation nutzen: Modi, in denen wenig Energie verbraucht wird +2. Entwicklung von Strategien, die langen Aufenthalt in energiesparenden Modi ermöglichen , und dabei Leistungsparameter in vertretbarem Umfang reduzieren +3. Implementieren dieser Strategien in Betriebssystemmechanismen zur Ressourcenverwaltung + +### Energieeffizientes Prozessormanagement +Hardware-Gegebenheiten +- z.Zt. meistgenutzte Halbleitertechnologie für Prozessor-Hardware: CMOS ( Complementary Metal Oxide Semiconductor) +- Komponenten für Energieverbrauch: $P = P_{switching} + P_{leakage} + ...$ + - $P_{switching}$: für Schaltvorgänge notwendige Leistung + - $P_{leakage}$: Verlustleistung durch verschiedene Leckströme + - ...: weitere Einflussgrößen (technologiespezifisch) + +#### Hardwareseitige Maßnahmen +Schaltleistung: $P_{switching}$ +- Energiebedarf kapazitiver Lade-u. Entladevorgänge während des Schaltens +- für momentane CMOS-Technologie i.A. dominanter Anteil am Energieverbrauch +- Einsparpotenzial: Verringerung von + 1. Versorgungsspannung (quadratische Abhängigkeit!) + 2. Taktfrequenz +- Folgen: + 1. längere Schaltvorgänge + 2. größere Latenzzwischen Schaltvorgängen +- Konsequenz: Energieeinsparung nur mit Qualitätseinbußen(direkt o. indirekt) möglich + - Anpassung des Lastprofils ( Zeit-Last-Kurve? Fristen kritisch? ) + - Beeinträchtigung der Nutzererfahrung( Reaktivität kritisch? Nutzungsprofil? ) + +Verlustleistung: $P_{leakage}$ +- Energiebedarf baulich bedingter Leckströme +- Fortschreitende Hardware-Miniaturisierung $\Rightarrow$ zunehmender Anteil von $P_{leakage}$ an P +- Beispielhafte Größenordnungen zum Einsparpotenzial: + | Schaltkreismaße | Versorgungsspannung | $P_{leakage}/P$ | + | --------------- | ------------------- | --------------- | + | 180 nm | 2,5 V | 0, | + | 70 nm | 0,7 V | 0, | + | 22 nm | 0,4 V | > 0,5 | +- Konsequenz: Leckströme kritisch für energiesparenden Hardwareentwurf + +#### Regelspielraum: Nutzererfahrung +- Nutzererwartung: wichtigstes Kriterium zur (subjektiven) Bewertung von auf einem Rechner aktiven Anwendungen durch Nutzer $\rightarrow$ Nutzerwartung bestimmt Nutzererfahrung +- Typ einer Anwendung + - entscheidet über jeweilige Nutzererwartung + 1. Hintergrundanwendung (z.B. Compiler); von Interesse: Gesamt-Bearbeitungsdauer, Durchsatz + 2. Echtzeitanwendung(z.B. Video-Player, MP3-Player); von Interesse: „flüssiges“ Abspielen von Video oder Musik + 3. Interaktive Anwendung (z.B. Webbrowser); von Interesse: Reaktivität, d.h. keine (wahrnehmbare) Verzögerung zwischen Nutzer-Aktion und Rechner-Reaktion + - Insbesondere kritisch: Echtzeitanwendungen, interaktive Anwendungen + +Reaktivität +- Reaktion von Anwendungen + - abhängig von sog. Reaktivität des Rechnersystems ≈ durchschnittliche Zeitdauer, mit der Reaktion eines Rechners auf eine (Benutzerinter-) Aktion erfolgt +- Reaktivität: von Reihe von Faktoren abhängig, z.B.: + 1. von **Hardware** an sich + 2. von **Energieversorgung** der Hardware (wichtig z.B. Spannungspegel an verschiedenen Stellen) + 3. von **Software-Gegebenheiten** (z.B. Prozess-Scheduling, Speichermanagement, Magnetplatten-E/A-Scheduling, Vorgänge im Fenstersystem, Arten des Ressourcen-Sharing usw.) + +Zwischenfazit: Nutzererfahrung +- bietet Regelspielraum für Hardwareparameter ( $\rightarrow$ Schaltleistung) $\rightarrow$ Versorgungsspannung, Taktfrequenz +- Betriebssystemmechanismen zum energieeffizienten Prozessormanagement müssen mit Nutzererfahrung(jeweils erforderlicher Reaktivität) ausbalanciert werden (wie solche Mechanismen wirken: 2.2.3) +- Schnittstelle zu anderen NFE: + - Echtzeitfähigkeit + - Performanz + - Usability + - ... + +#### Energieeffizientes Scheduling +- so weit besprochen: Beschränkung des durchschnittlichen Energieverbrauchs eines Prozessors +- offene Frage zum Ressourcenmultiplexing: Energieverbrauch eines Threads/Prozesses? +- Scheduling-Probleme beim Energiesparen: + 1. Fairness (der Energieverteilung)? + 2. Prioritätsumkehr? +- Beispiel: Round Robin (RR) mit Prioritäten (Hoch, Mittel, Niedrig) +- Problem 1: Unfaire Energieverteilung + - Beschränkung des Energieverbrauchs (durch Qualitätseinbußen, schlimmstenfalls Ausfall)ab einem oberen Schwellwert $E_{max}$ + - Problem: energieintensive Threads behindern alle nachfolgenden Threads trotz gleicher Priorität $\rightarrow$ Fairnessmaß von RR (gleiche Zeitscheibenlänge T ) untergraben + - ![](Assets/AdvancedOperatingSystems-round-robin-unfair.png) +- Problem 2: energieintensive Threads niedrigerer Priorität behindern später ankommende Threads höherer Priorität + - ![](Assets/AdvancedOperatingSystems-prioritätsumkehr.png) + +Energiebewusstes RR: Fairness +- Begriffe: + - $E_i^{budget}$ ... Energiebudget von $t_i$ + - $E_i^{limit}$ ... Energielimit von $t_i$ + - $P_{limit}$ ... Leistungslimit: maximale Leistungsaufnahme [Energie/Zeit] + - $T$ ... resultierende Zeitscheibenlänge +- Strategie 1: faire Energieverteilung (einheitliche Energielimits) + - ![Darstellung nach Klee08](Assets/AdvancedOperatingSystems-energiebewusstes-rr.png) + - $1\leq i\leq 4: E_i^{limit} = P_{limit}* T$ + - (Abweichungen = Wichtung der Prozesse $\rightarrow$ bedingte Fairness) + +Energiebewusstes RR: Reaktivität +- faire bzw. gewichtete Aufteilung begrenzter Energie optimiert Energieeffizienz +- Problem: lange, wenig energieintensive Threads verzögern Antwort-und Wartezeiten kurzer, energieintensiver Threads + - Lösung im Einzelfall: Wichtung per $E_i^{limit}$ + - globale Reaktivität ( $\rightarrow$ Nutzererfahrung bei interaktiven Systemen) ...? +- Strategie 2: maximale Reaktivität ( $\rightarrow$ klassisches RR) + - ![](Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png) + +Energiebewusstes RR: Reaktivität und Fairness +- Problem: sparsame Threads werden bestraft durch Verfallen des ungenutzten Energiebudgets +- Idee: Ansparen von Energiebudgets $\rightarrow$ mehrfache Ausführung eines Threads innerhalb einer Scheduling-Periode +- Strategie 3: Reaktivität, dann faire Energieverteilung + - ![](Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png) + +##### Implementierungsfragen +- Scheduling-Zeitpunkte? + - welche Accounting-Operationen (Buchführung über Budget)? + - wann Accounting-Operationen? + - wann Verdrängung? +- Datenstrukturen? + - ... im Scheduler $\rightarrow$ Warteschlange(n)? + - ... im Prozessdeskriptor? +- Kosten ggü. klassischem RR? (durch Prioritäten...?) + +- Pro: + - Optimierung der Energieverteilung nach anwendungsspezifischen Schedulingzielen( $\rightarrow$ Strategien) + - Berücksichtigung von prozessspezifischen Energieverbrauchsmustern möglich:fördert Skalierbarkeit i.S.v. Lastadaptivität, indirekt auch Usability ( $\rightarrow$ Nutzererfahrung) +- Kontra: + - zusätzliche sekundäre Kosten: Energiebedarf des Schedulers, Energiebedarf zusätzlicher Kontextwechsel, Implementierungskosten (Rechenzeit, Speicher) + - Voraussetzung hardwareseitig: Monitoring des Energieverbrauchs (erforderliche/realisierbare Granularität...? sonst: Extrapolation?) +- **generelle Alternative:** energieintensive Prozesse verlangsamen $\rightarrow$ Regelung der CPU-Leistungsparameter (Versorgungsspannung) (auch komplementär zum Schedulingals Maßnahme nach Energielimit-Überschreitung) +- Beispiel: Synergie nichtfunktionaler Eigenschaften + - Performanz nur möglich durch Parallelität $\rightarrow$ Multicore-Hardware + - Multicore-Hardware nur möglich mit Lastausgleich und Lastverteilungauf mehrere CPUs + - dies erfordert ebenfalls Verteilungsstrategien: „Energy-aware Scheduling“ (Linux-Strategie zur Prozessorallokation -nicht zeitlichem Multiplexing!) + +### Systemglobale Energieeinsparungsmaßnahmen +- Traditionelle Betriebssysteme: Entwurf so, dass zu jedem Zeitpunkt Spitzen-Performanzangestrebt +- Beobachtungen: + - viele Anwendungen benötigen keine Spitzen-Performanz + - viele Hardware-Komponenten verbringen Zeit in Leerlaufsituationen bzw. in Situationen, wo keine Spitzen-Performanz erforderlich +- Konsequenz (besonders für mobile Systeme) : + - Hardware mit Niedrigenergiezuständen(Prozessoren und Magnetplattenlaufwerke, aber auch DRAM, Netzwerkschnittstellen, Displays, ...) + - somit kann Betriebssystem **Energie-Management** realisieren + +#### Hardwaretechnologien +- DPM: Dynamic Power Management + - versetzt leerlaufende/unbenutzte Hardware-Komponenten selektiv in Zustände mit niedrigem Energieverbrauch + - Zustandsübergänge durch Power-Manager (in Hardware) gesteuert, dem bestimmte _DPM-_ Strategie (Firmware) zugrunde liegt, um gutes Verhältnis zwischen Performanz/Reaktivität und Energieeinsparung zu erzielen +- DVS: Dynamic Voltage Scaling + - effizientes Verfahren zur dynamischen Regulierungvon Taktfrequenz gemeinsammit Versorgungsspannung + - Nutzung quadratischer Abhängigkeitder dynamischen Leistung von Versorgungsspannung + - Steuerung/Strategien: Softwareunterstützungnotwendig! + +Dynamisches Energiemanagement (DPM)- Strategien (Klassen) bestimmt, wann und wie lange eine Hardware-Komponente sich in Energiesparmodusbefinden sollte +- Greedy: Hardware-Komponente sofort nach Erreichen des Leerlaufs in Energiesparmodus, „Aufwecken“ durch neue Anforderung +- Time-out: Energiesparmodus erst nachdem ein definiertes Intervall im Leerlauf, „Aufwecken“ wie bei Greedy-Strategien +- Vorhersage: Energiesparmodus sofort nach Erreichen des Leerlaufs, wenn Heuristik vorhersagt,dass Kosten gerechtfertigt +- Stochastisch: Energiesparmodus auf Grundlage eines stochastischen Modells + +Spannungsskalierung (DVS) +- Ziel: Unterstützung von DPM-Strategien durch Maßnahmen auf Ebene von Compiler, Betriebssystem und Applikationen: + - **Compiler** + - kann Informationen zur Betriebssystem-Unterstützung bezüglich Spannungs-Einstellung in Anwendungs-Code einstreuen, + - damit zur Laufzeit Informationen über jeweilige Arbeitslast verfügbar +- **Betriebssystem (prädiktives Energiemanagement)** + - kann Benutzung verschiedener Ressourcen (Prozessor usw.) beobachten + - kann darüber Vorhersagen tätigen + - kann notwendigen Performanzbereich bestimmen +- **Anwendungen** + - können Informationen über jeweils für sie notwendige Performanz liefern +- $\rightarrow$ Kombination mit energieefizientemScheduling! + +## Speichereffizienz +- ... heißt: Auslastung des verfügbaren Speichers + - oft implizit: Hauptspeicherauslastung (memoryfootprint) + - besonders für kleine/mobile Systeme: Hintergrundspeicherauslastung +- Maße zur Konkretisierung: + - zeitliche Dimension: Maximum vs. Summe genutzten Speichers? + - physischer Speicherverwaltung? $\rightarrow$ Belegungsanteil pAR + - virtuelle Speicherverwaltung? $\rightarrow$ Belegungsanteil vAR +- Konsequenzen für Ressourcenverwaltung durch BS: + - Taskverwaltung (Accounting, Multiplexing, Fairness, ...) + - Programmiermodell, API (besonders: dynamische Speicherreservierung) + - Sinnfrage und ggf. Strategien virtueller Speicherverwaltung (VMM) +- Konsequenzen für Betriebssystem selbst: + - minimaler Speicherbedarfdurch Kernel + - minimale Speicherverwaltungskosten (durch obige Aufgaben) + +### Hauptspeicherauslastung +- ![](Assets/AdvancedOperatingSystems-speicherverwaltung.png) + +Problem: externe Fragmentierung +- ![](Assets/AdvancedOperatingSystems-externe-fragmentierung.png) +- Lösungen: + - First Fit, Best Fit, WorstFit, Buddy + - Relokation +- Kompromissloser Weg: kein Multitasking! + +Problem: interne Fragmentierung +- ![](Assets/AdvancedOperatingSystems-interne-fragmentierung.png) +- Lösung: + - Seitenrahmengröße verringern + - Tradeoff: dichter belegte vAR $\rightarrow$ größere Datenstrukturen für Seitentabellen! + +- direkter Einfluss des Betriebssystems auf Hauptspeicherbelegung: + - $\rightarrow$ Speicherbedarf des Kernels + - statische(Minimal-) Größe des Kernels (Anweisungen + Daten) + - dynamischeSpeicherreservierung durch Kernel + - bei Makrokernel: Speicherbedarf von Gerätecontrollern (Treibern)! + +weitere Einflussfaktoren: Speicherverwaltungskosten +- VMM: Seitentabellengröße $\rightarrow$ Mehrstufigkeit +- Metainformationen über laufende Programme: Größe von Taskkontrollblöcken( Prozess-/Threaddeskriptoren ...) +- dynamische Speicherreservierung durch Tasks + +##### Beispiel 1: sparsam +Prozesskontrollblock (PCB, Metadatenstruktur des Prozessdeskriptors) eines kleinen Echtzeit-Kernels („DICK“): +```cpp +// Process Control Block (PCB) +struct pcb { + char name[MAXLEN +1]; // process name + proc (*addr)(); // first instruction + int type; // process type + int state; // process state + long dline; // absolute deadline + int period; // period + int prt; // priority + int wcet; // worst-case execution time + float util; // processor utilization + int *context; + proc next; + proc prev; +}; +``` + +##### Beispiel 2: eher nicht sparsam +Linux Prozesskontrollblock (taskstruct): +```cpp +struct task_struct { + volatile long state; /* - 1 unrunnable, 0 runnable, >0 stopped */ + void *stack; + atomic_t usage; + unsigned int flags; /* per process flags, defined below */ + unsigned int ptrace; +#ifdef CONFIG_SMP + struct llist_node wake_entry; + int on_cpu; +#endif + int on_rq; +// SCHEDULING INFORMATION + int prio, static_prio, normal_prio; + unsigned int rt_priority; + const struct sched_class *sched_class; +// Scheduling Entity + struct sched_entity se; + struct sched_rt_entity rt; +#ifdef CONFIG_CGROUP_SCHED + struct task_group *sched_task_group; +#endif +#ifdef CONFIG_PREEMPT_NOTIFIERS + struct hlist_head preempt_notifiers; /* list of struct preempt_notifier */ +#endif + unsigned char fpu_counter; +#ifdef CONFIG_BLK_DEV_IO_TRACE + unsigned int btrace_seq; +#endif + unsigned int policy; + cpumask_t cpus_allowed; +#ifdef CONFIG_PREEMPT_RCU + int rcu_read_lock_nesting; + char rcu_read_unlock_special; + struct list_head rcu_node_entry; + struct rcu_node *rcu_blocked_node; +#endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */ +#ifdef CONFIG_RCU_BOOST + struct rt_mutex *rcu_boost_mutex; +#endif /* #ifdef CONFIG_RCU_BOOST */ +#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT) + struct sched_info sched_info; +#endif + struct list_head tasks; +#ifdef CONFIG_SMP + struct plist_node pushable_tasks; +#endif +// virtual address space reference + struct mm_struct *mm, *active_mm; +#ifdef CONFIG_COMPAT_BRK + unsigned brk_randomized:1; +#endif +#if defined(SPLIT_RSS_COUNTING) + struct task_rss_stat rss_stat; +#endif +/* task state */ + int exit_state; + int exit_code, exit_signal; + int pdeath_signal; /* The signal sent when the parent dies */ + unsigned int jobctl; /* JOBCTL_*, siglock protected */ + unsigned int personality; + unsigned did_exec:1; + unsigned in_execve:1;/* Tell the LSMs that the process is doing an * execve */ + unsigned in_iowait:1; +/* Revert to default priority/policy when forking */ + unsigned sched_reset_on_fork:1; + unsigned sched_contributes_to_load:1; +#ifdef CONFIG_GENERIC_HARDIRQS +/* IRQ handler threads */ + unsigned irq_thread; +#endif + pid_t pid; + pid_t tgid; +#ifdef CONFIG_CC_STACKPROTECTOR +/* Canary value for the -fstack-protector gcc feature */ + unsigned long stack_canary; +#endif +// Relatives + struct task_struct __rcu *real_parent; /* real parent process */ + struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */ +/* children/sibling forms the list of my natural children */ + struct list_head children; /* list of my children */ + struct list_head sibling; /* linkage in my parent's children list */ + struct task_struct *group_leader; /* threadgroup leader */ + struct list_head ptraced; + struct list_head ptrace_entry; +/* PID/PID hash table linkage. */ + struct pid_link pids[PIDTYPE_MAX]; + struct list_head thread_group; + struct completion *vfork_done; /* for vfork() */ + int __user *set_child_tid; +... + unsigned long timer_slack_ns; + unsigned long default_timer_slack_ns; + struct list_head *scm_work_list; +#ifdef CONFIG_FUNCTION_GRAPH_TRACER +/* Index of current stored address in ret_stack */ + int curr_ret_stack; +/* Stack of return addresses for return function tracing */ + struct ftrace_ret_stack *ret_stack; +/* time stamp for last schedule */ + unsigned long long ftrace_timestamp; +... +``` + +### Hintergrundspeicherauslastung +Einflussfaktoren des Betriebssystems: +- statische Größe des Kernel-Images, welches beim Bootstrapping gelesen wird +- statische Größe von Programm-Images (Standards wie ELF) +- statisches vs. dynamisches Einbinden von Bibliotheken: Größe von Programmdateien +- VMM: Größe des Auslagerungsbereichs (inkl. Teilen der Seitentabelle!) für Anwendungen +- Modularisierung (zur Kompilierzeit) des Kernels: gezielte Anpassung an Einsatzdomäne möglich +- Adaptivität (zur Kompilier-und Laufzeit) des Kernels: gezielte Anpassung an sich ändernde Umgebungsbedingungen möglich ($\rightarrow$ Cassini-Huygens-Mission) + + # Robustheit und Verfügbarkeit # Sicherheit # Echtzeitfähigkeit @@ -162,10 +641,30 @@ Diskussion jeder Eigenschaft: (Bsp.: Echtzeitfähigkeit) # Literatur - - NFE in Betriebssystemen - Eeles, Peter; Cripps, Peter: The Process of Software Architecting - Funktionale Eigenschaften eines Betriebssystem - Tanebaum, Andrews; Bos, Herbert: Modern Operating Systems - Tanebaum, Andrews; Woodhull, Alberts: Operating Systems Design and Implementation - - Stallings, William: Operating Systems: Internals and Design Principles \ No newline at end of file + - Stallings, William: Operating Systems: Internals and Design Principles +- Energieeffizienz + - GUPTA, RAJESHK.; IRANI, SANDY; SHUKLA, SANDEEPK.; SHUKLA, SANDEEPK.: Formal Methods for Dynamic Power Management + - RANGANATHAN, PARTHASARATHY: Recipe for efficiency: principles of power-aware computing + - SIMUNIC, TAJANA; BENINI, LUCA; GLYNN, PETER; DEMICHELI, GIOVANNI: Dynamic Power Management for Portable Systems +- Effiziente Hauptspeicherverwaltung + - DINIZ, BRUNO; GUEDES, DORGIVAL; MEIRA, WAGNER, JR.; BIANCHINI, RICARDO: Limiting the Power Consumption of Main Memory +- Traditionelles Festplatten-Prefetching + - CAO, PEI; FELTEN, EDWARDW.; KARLIN, ANNAR.; LI, KAI: A Study ofIntegrated Prefetching and Caching Strategies +- Effizienter Betrieb von Festplatten + - PAPATHANASIOU, ATHANASIOSE.; SCOTT, MICHAELL.: Energy Efficient Prefetching and Caching +- Energieeffizientes Scheduling + - KLEE, CHRISTOPH: Design and Analysis of Energy-Aware Scheduling Policies +- Energieeffiziente Betriebssysteme + - LANG, CLEMENS: Components for Energy-Efficient Operating Systems + - YAN, LE; ZHONG, LIN; JHA, NIRAJK.: Towards a Responsive, Yet Power-efficient, Operating System: A Holistic Approach + - YAN, LE; ZHONG, LIN; JHA, NIRAJK.: User-perceived Latency Driven Voltage Scaling for Interactive Applications +- Eingebettete Systeme + - MANLEY, JOHNH.: Embedded Systems, MARCINIAK, J. J.(Hrsg.) +- TinyOS + - KELLNER, SIMON; BELLOSA, FRANK: Energy Accounting Support in TinyOS + - KELLNER, SIMON: Flexible Online Energy Accounting in TinyOS \ No newline at end of file diff --git a/Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png b/Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png new file mode 100644 index 0000000..b819e53 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png differ diff --git a/Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png b/Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png new file mode 100644 index 0000000..857b5ab Binary files /dev/null and b/Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png differ diff --git a/Assets/AdvancedOperatingSystems-energiebewusstes-rr.png b/Assets/AdvancedOperatingSystems-energiebewusstes-rr.png new file mode 100644 index 0000000..4cc56db Binary files /dev/null and b/Assets/AdvancedOperatingSystems-energiebewusstes-rr.png differ diff --git a/Assets/AdvancedOperatingSystems-energiezustände-festplatte.png b/Assets/AdvancedOperatingSystems-energiezustände-festplatte.png new file mode 100644 index 0000000..891b53d Binary files /dev/null and b/Assets/AdvancedOperatingSystems-energiezustände-festplatte.png differ diff --git a/Assets/AdvancedOperatingSystems-externe-fragmentierung.png b/Assets/AdvancedOperatingSystems-externe-fragmentierung.png new file mode 100644 index 0000000..b36f562 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-externe-fragmentierung.png differ diff --git a/Assets/AdvancedOperatingSystems-interne-fragmentierung.png b/Assets/AdvancedOperatingSystems-interne-fragmentierung.png new file mode 100644 index 0000000..4dd072b Binary files /dev/null and b/Assets/AdvancedOperatingSystems-interne-fragmentierung.png differ diff --git a/Assets/AdvancedOperatingSystems-prioritätsumkehr.png b/Assets/AdvancedOperatingSystems-prioritätsumkehr.png new file mode 100644 index 0000000..2ac0fc5 Binary files /dev/null and b/Assets/AdvancedOperatingSystems-prioritätsumkehr.png differ diff --git a/Assets/AdvancedOperatingSystems-round-robin-unfair.png b/Assets/AdvancedOperatingSystems-round-robin-unfair.png new file mode 100644 index 0000000..b85631c Binary files /dev/null and b/Assets/AdvancedOperatingSystems-round-robin-unfair.png differ diff --git a/Assets/AdvancedOperatingSystems-speicherverwaltung.png b/Assets/AdvancedOperatingSystems-speicherverwaltung.png new file mode 100644 index 0000000..0cdf9cc Binary files /dev/null and b/Assets/AdvancedOperatingSystems-speicherverwaltung.png differ