energieeffizientes Scheduling
This commit is contained in:
parent
19d990abd7
commit
ae4d78fec7
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -309,350 +309,173 @@
|
|||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
|
|
||||||
\subsubsection{Energieeffizientes Prozessormanagement}
|
\subsubsection{Energieeffizientes Prozessormanagement}
|
||||||
Hardware-Gegebenheiten
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item z.Zt. meistgenutzte Halbleitertechnologie für Prozessor-Hardware: CMOS ( Complementary Metal Oxide Semiconductor)
|
\item CMOS z.Zt. meistgenutzte Halbleitertechnologie für Prozessor
|
||||||
\item
|
\item Komponenten für Energieverbrauch $P = P_{switch} + P_{leak} + ...$
|
||||||
Komponenten für Energieverbrauch: $P = P_{switching} +
|
|
||||||
P_{leakage} + ...$
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item $P_{switching}$: für Schaltvorgänge notwendige Leistung
|
\item $P_{switch}$: für Schaltvorgänge notwendige Leistung
|
||||||
\item $P_{leakage}$: Verlustleistung durch verschiedene Leckströme
|
\item $P_{leak}$: Verlustleistung durch verschiedene Leckströme
|
||||||
\item ...: weitere Einflussgrößen (technologiespezifisch)
|
\item ...: weitere Einflussgrößen (technologiespezifisch)
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Hardwareseitige
|
|
||||||
Maßnahmen}
|
|
||||||
|
|
||||||
Schaltleistung: $P_{switching}$
|
Schaltleistung: $P_{switching}$
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Energiebedarf kapaz. Lade-/Entladevorgänge während Schaltens
|
||||||
Energiebedarf kapazitiver Lade-u. Entladevorgänge während des
|
\item für momentane CMOS dominanter Anteil am Energieverbrauch
|
||||||
Schaltens
|
\item Einsparpotenzial: Verringerung von Versorgungsspannung (quadratische Abhängigkeit!) und Taktfrequenz
|
||||||
\item
|
\item[$\rightarrow$] längere Schaltvorgänge, größere Latenz zwischen Schaltvorgängen
|
||||||
für momentane CMOS-Technologie i.A. dominanter Anteil am
|
\item[$\Rightarrow$] Energieeinsparung nur mit Qualitätseinbußen
|
||||||
Energieverbrauch
|
\begin{itemize*}
|
||||||
\item
|
\item Anpassung des Lastprofils (Zeit-Last? Fristen kritisch?)
|
||||||
Einsparpotenzial: Verringerung von
|
\item Beeinträchtigung der Nutzererfahrung (Reaktivität?)
|
||||||
|
\end{itemize*}
|
||||||
|
\end{itemize*}
|
||||||
|
|
||||||
|
Verlustleistung: $P_{leak}$
|
||||||
|
\begin{itemize*}
|
||||||
|
\item Energiebedarf baulich bedingter Leckströme
|
||||||
|
\item Hardware-Miniaturisierung $\rightarrow$ zunehmender Anteil $P_{leak}$ an P
|
||||||
|
\item[$\Rightarrow$] Leckströme kritisch für energiesparenden Hardwareentwurf
|
||||||
|
\end{itemize*}
|
||||||
|
|
||||||
|
Regelspielraum: Nutzererfahrung
|
||||||
|
\begin{itemize*}
|
||||||
|
\item Nutzererwartung: wichtigstes Kriterium zur Bewertung von auf einem Rechner aktiven Anwendungen durch Nutzer $\rightarrow$ Nutzererwartung bestimmt Nutzererfahrung
|
||||||
|
\item Typ einer Anwendung entscheidet über jeweilige Nutzererwartung
|
||||||
\begin{enumerate*}
|
\begin{enumerate*}
|
||||||
|
\item Hintergrund (z.B. Compiler): Gesamt-Bearbeitungsdauer, Durchsatz
|
||||||
\item Versorgungsspannung (quadratische Abhängigkeit!)
|
\item Echtzeit (z.B. Video-Player): ,,flüssiges'' Abspielen von Video oder Musik
|
||||||
\item Taktfrequenz
|
\item Interaktiv (z.B. Webbrowser): Reaktivität, d.h. keine (wahrnehmbare) Verzögerung zwischen Nutzer-Aktion und Rechner-Reaktion
|
||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
\item
|
\item Insbesondere kritisch: Echtzeit-/interaktive Anwendungen
|
||||||
Folgen:
|
\item Reaktivität: Reaktion von Anwendungen; abhängig z.B. von
|
||||||
\begin{enumerate*}
|
\begin{enumerate*}
|
||||||
|
\item \textbf{Hardware} an sich
|
||||||
\item längere Schaltvorgänge
|
\item \textbf{Energieversorgung} der Hardware (z.B. Spannungspegel)
|
||||||
\item größere Latenzzwischen Schaltvorgängen
|
\item \textbf{Software-Gegebenheiten} (z.B. Scheduling, Management)
|
||||||
\end{enumerate*}
|
\end{enumerate*}
|
||||||
\item
|
\item Zwischenfazit: Nutzererfahrung
|
||||||
Konsequenz: Energieeinsparung nur mit Qualitätseinbußen(direkt o.
|
|
||||||
indirekt) möglich
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Anpassung des Lastprofils ( Zeit-Last-Kurve? Fristen kritisch? )
|
\item bietet Regelspielraum für Hardwareparameter
|
||||||
\item Beeinträchtigung der Nutzererfahrung( Reaktivität kritisch? Nutzungsprofil? )
|
\item Betriebssystemmechanismen zum energieeffizienten Prozessormanagement müssen mit Nutzererfahrung(jeweils erforderlicher Reaktivität)
|
||||||
|
ausbalanciert werden
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
Verlustleistung: $P_{leakage}$
|
\subsubsection{Energieeffizientes Scheduling}
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Scheduling-Probleme beim Energiesparen: Fairness \& Prioritätsumkehr
|
||||||
Energiebedarf baulich bedingter Leckströme
|
\item Beispiel: Round Robin (RR) mit Prioritäten
|
||||||
\item
|
|
||||||
Fortschreitende Hardware-Miniaturisierung
|
|
||||||
$\rightarrow$ zunehmender Anteil von
|
|
||||||
$P_{leakage}$ an P
|
|
||||||
\item
|
|
||||||
Beispielhafte Größenordnungen zum Einsparpotenzial: \textbar{}
|
|
||||||
Schaltkreismaße \textbar{} Versorgungsspannung \textbar{}
|
|
||||||
$P_{leakage}/P$ \textbar{} \textbar{}
|
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
|
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
|
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} 180
|
|
||||||
nm \textbar{} 2,5 V \textbar{} 0, \textbar{} \textbar{} 70 nm
|
|
||||||
\textbar{} 0,7 V \textbar{} 0, \textbar{} \textbar{} 22 nm \textbar{}
|
|
||||||
0,4 V \textbar{} \textgreater{} 0,5 \textbar{}
|
|
||||||
\item
|
|
||||||
Konsequenz: Leckströme kritisch für energiesparenden Hardwareentwurf
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Regelspielraum:
|
|
||||||
Nutzererfahrung}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Nutzererwartung: wichtigstes Kriterium zur (subjektiven) Bewertung von
|
|
||||||
auf einem Rechner aktiven Anwendungen durch Nutzer
|
|
||||||
$\rightarrow$ Nutzerwartung bestimmt Nutzererfahrung
|
|
||||||
\item
|
|
||||||
Typ einer Anwendung
|
|
||||||
\begin{itemize*}
|
|
||||||
\item entscheidet über jeweilige Nutzererwartung \begin{enumerate*} \item Hintergrundanwendung (z.B. Compiler); von Interesse: Gesamt-Bearbeitungsdauer, Durchsatz \item Echtzeitanwendung(z.B. Video-Player, MP3-Player); von Interesse: ,,flüssiges'' Abspielen von Video oder Musik \item Interaktive Anwendung (z.B. Webbrowser); von Interesse: Reaktivität, d.h. keine (wahrnehmbare) Verzögerung zwischen Nutzer-Aktion und Rechner-Reaktion \end{enumerate*}
|
|
||||||
\item Insbesondere kritisch: Echtzeitanwendungen, interaktive Anwendungen
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
Reaktivität
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Reaktion von Anwendungen
|
|
||||||
\begin{itemize*}
|
|
||||||
\item abhängig von sog. Reaktivität des Rechnersystems $\approx$ durchschnittliche Zeitdauer, mit der Reaktion eines Rechners auf eine (Benutzerinter-) Aktion erfolgt
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
Reaktivität: von Reihe von Faktoren abhängig, z.B.:
|
|
||||||
\begin{enumerate*}
|
|
||||||
|
|
||||||
\item von \textbf{Hardware} an sich
|
|
||||||
\item von \textbf{Energieversorgung} der Hardware (wichtig z.B. Spannungspegel an verschiedenen Stellen)
|
|
||||||
\item von \textbf{Software-Gegebenheiten} (z.B. Prozess-Scheduling, Speichermanagement, Magnetplatten-E/A-Scheduling, Vorgänge im Fenstersystem, Arten des Ressourcen-Sharing usw.)
|
|
||||||
\end{enumerate*}
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
Zwischenfazit: Nutzererfahrung
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
bietet Regelspielraum für Hardwareparameter (
|
|
||||||
$\rightarrow$ Schaltleistung)
|
|
||||||
$\rightarrow$ Versorgungsspannung, Taktfrequenz
|
|
||||||
\item
|
|
||||||
Betriebssystemmechanismen zum energieeffizienten Prozessormanagement
|
|
||||||
müssen mit Nutzererfahrung(jeweils erforderlicher Reaktivität)
|
|
||||||
ausbalanciert werden (wie solche Mechanismen wirken: 2.2.3)
|
|
||||||
\item
|
|
||||||
Schnittstelle zu anderen NFE:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Echtzeitfähigkeit
|
|
||||||
\item Performanz
|
|
||||||
\item Usability
|
|
||||||
\item ...
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Energieeffizientes Scheduling}
|
|
||||||
\begin{itemize*}
|
|
||||||
\item so weit besprochen: Beschränkung des durchschnittlichen Energieverbrauchs eines Prozessors
|
|
||||||
\item offene Frage zum Ressourcenmultiplexing: Energieverbrauch eines Threads/Prozesses?
|
|
||||||
\item Scheduling-Probleme beim Energiesparen:
|
|
||||||
\begin{enumerate*}
|
|
||||||
\item Fairness (der Energieverteilung)?
|
|
||||||
\item Prioritätsumkehr?
|
|
||||||
\end{enumerate*}
|
|
||||||
\item Beispiel: Round Robin (RR) mit Prioritäten (Hoch, Mittel, Niedrig)
|
|
||||||
\item Problem 1: Unfaire Energieverteilung
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Beschränkung des Energieverbrauchs (durch Qualitätseinbußen, schlimmstenfalls Ausfall)ab einem oberen Schwellwert $E_{max}$
|
|
||||||
\item Problem: energieintensive Threads behindern alle nachfolgenden Threads trotz gleicher Priorität $\rightarrow$ Fairnessmaß von RR (gleiche Zeitscheibenlänge T ) untergraben
|
|
||||||
%\begin{itemize*}
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-round-robin-unfair.png} \end{itemize*}
|
|
||||||
%\end{itemize*}
|
|
||||||
\item Problem 2: energieintensive Threads niedrigerer Priorität behindern
|
|
||||||
später ankommende Threads höherer Priorität
|
|
||||||
%\begin{itemize*}
|
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-prioritätsumkehr.png}
|
|
||||||
%\end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
Energiebewusstes RR: Fairness
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Begriffe:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item $E_i^{budget}$ ... Energiebudget von $t_i$
|
\item $E_i^{budget}$ ... Energiebudget von $t_i$
|
||||||
\item $E_i^{limit}$ ... Energielimit von $t_i$
|
\item $E_i^{limit}$ ... Energielimit von $t_i$
|
||||||
\item $P_{limit}$ ... Leistungslimit: maximale Leistungsaufnahme [Energie/Zeit]
|
\item $P_{limit}$ ... maximale Leistungsaufnahme [Energie/Zeit]
|
||||||
\item $T$ ... resultierende Zeitscheibenlänge
|
\item $T$ ... resultierende Zeitscheibenlänge
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item Problem 1: Unfaire Energieverteilung
|
||||||
Strategie 1: faire Energieverteilung (einheitliche Energielimits)
|
%\item Beschränkung des Energieverbrauchs (durch Qualitätseinbußen, schlimmstenfalls Ausfall) ab einem oberen Schwellwert $E_{max}$
|
||||||
|
\item Problem 2: energieintensive Threads behindern nachfolgende Threads gleicher Priorität
|
||||||
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-round-robin-unfair.png} \end{itemize*}
|
||||||
|
\item Problem 3: energieintensive Threads niedrigerer Priorität behindern spätere Threads höherer Priorität
|
||||||
|
%\begin{itemize*}
|
||||||
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-prioritätsumkehr.png}
|
||||||
|
%\end{itemize*}
|
||||||
|
\item RR Strategie 1: faire Energieverteilung (einheitliche Energielimits)
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
%\item
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewusstes-rr.png}
|
||||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewusstes-rr.png}
|
|
||||||
\item $1\leq i\leq 4: E_i^{limit} = P_{limit}* T$
|
\item $1\leq i\leq 4: E_i^{limit} = P_{limit}* T$
|
||||||
\item (Abweichungen = Wichtung der Prozesse $\rightarrow$ bedingte Fairness)
|
%\item (Abweichungen = Wichtung der Prozesse $\rightarrow$ bedingte Fairness)
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\item faire bzw. gewichtete Aufteilung begrenzter Energie optimiert Energieeffizienz
|
||||||
|
\item Problem: lange, wenig energieintensive Threads verzögern Antwort-und Wartezeiten kurzer, energieintensiver Threads
|
||||||
Energiebewusstes RR: Reaktivität
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
faire bzw. gewichtete Aufteilung begrenzter Energie optimiert
|
|
||||||
Energieeffizienz
|
|
||||||
\item
|
|
||||||
Problem: lange, wenig energieintensive Threads verzögern Antwort-und
|
|
||||||
Wartezeiten kurzer, energieintensiver Threads
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Lösung im Einzelfall: Wichtung per $E_i^{limit}$
|
\item Lösung im Einzelfall: Wichtung per $E_i^{limit}$
|
||||||
\item globale Reaktivität ( $\rightarrow$ Nutzererfahrung bei interaktiven Systemen) ...?
|
\item globale Reaktivität $\rightarrow$ Nutzererfahrung?
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item RR Strategie 2: maximale Reaktivität ( $\rightarrow$ klassisches RR)
|
||||||
Strategie 2: maximale Reaktivität ( $\rightarrow$
|
|
||||||
klassisches RR)
|
|
||||||
%\begin{itemize*}
|
%\begin{itemize*}
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png}
|
||||||
%\end{itemize*}
|
%\end{itemize*}
|
||||||
\end{itemize*}
|
\item Problem: sparsame Threads werden bestraft durch Verfallen des ungenutzten Energiebudgets
|
||||||
|
\item Idee: Ansparen von Energiebudgets $\rightarrow$ mehrfache Ausführung eines Threads innerhalb einer Scheduling-Periode
|
||||||
Energiebewusstes RR: Reaktivität und Fairness
|
\item RR Strategie 3: Reaktivität, dann faire Energieverteilung
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Problem: sparsame Threads werden bestraft durch Verfallen des
|
|
||||||
ungenutzten Energiebudgets
|
|
||||||
\item
|
|
||||||
Idee: Ansparen von Energiebudgets $\rightarrow$
|
|
||||||
mehrfache Ausführung eines Threads innerhalb einer Scheduling-Periode
|
|
||||||
\item
|
|
||||||
Strategie 3: Reaktivität, dann faire Energieverteilung
|
|
||||||
%\begin{itemize*}
|
%\begin{itemize*}
|
||||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png}
|
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png}
|
||||||
%\end{itemize*}
|
%\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
Implementierungsfragen
|
||||||
\subparagraph{Implementierungsfragen}
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Kosten ggü. klassischem RR? (durch Prioritäten...?)
|
||||||
Scheduling-Zeitpunkte?
|
\item Scheduling-Zeitpunkte?
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item welche Accounting-Operationen (Buchführung über Budget)?
|
\item welche Accounting-Operationen (Buchführung)?
|
||||||
\item wann Accounting-Operationen?
|
\item wann Accounting-Operationen?
|
||||||
\item wann Verdrängung?
|
\item wann Verdrängung?
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item Datenstrukturen?
|
||||||
Datenstrukturen?
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item ... im Scheduler $\rightarrow$ Warteschlange(n)?
|
\item ... im Scheduler $\rightarrow$ Warteschlange(n)?
|
||||||
\item ... im Prozessdeskriptor?
|
\item ... im Prozessdeskriptor?
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item Pro
|
||||||
Kosten ggü. klassischem RR? (durch Prioritäten...?)
|
|
||||||
\item
|
|
||||||
Pro:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Optimierung der Energieverteilung nach anwendungsspezifischen Schedulingzielen( $\rightarrow$ Strategien)
|
\item Optimierung der Energieverteilung nach Schedulingzielen
|
||||||
\item Berücksichtigung von prozessspezifischen Energieverbrauchsmustern möglich:fördert Skalierbarkeit i.S.v. Lastadaptivität, indirekt auch Usability ( $\rightarrow$ Nutzererfahrung)
|
\item Berücksichtigung prozessspezifischer Verbrauchsmuster
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item Kontra
|
||||||
Kontra:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item zusätzliche sekundäre Kosten: Energiebedarf des Schedulers, Energiebedarf zusätzlicher Kontextwechsel, Implementierungskosten (Rechenzeit, Speicher)
|
\item sekundäre Kosten: Energiebedarf des Schedulers, Kontextwechsel, Implementierungskosten
|
||||||
\item Voraussetzung hardwareseitig: Monitoring des Energieverbrauchs (erforderliche/realisierbare Granularität...? sonst: Extrapolation?)
|
\item Voraussetzung: Monitoring des Energieverbrauchs
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
\textbf{generelle Alternative:} energieintensive Prozesse verlangsamen
|
|
||||||
$\rightarrow$ Regelung der CPU-Leistungsparameter
|
|
||||||
(Versorgungsspannung) (auch komplementär zum Schedulingals Maßnahme
|
|
||||||
nach Energielimit-Überschreitung)
|
|
||||||
\item
|
|
||||||
Beispiel: Synergie nichtfunktionaler Eigenschaften
|
|
||||||
\begin{itemize*}
|
|
||||||
\item Performanz nur möglich durch Parallelität $\rightarrow$ Multicore-Hardware
|
|
||||||
\item Multicore-Hardware nur möglich mit Lastausgleich und Lastverteilungauf mehrere CPUs
|
|
||||||
\item dies erfordert ebenfalls Verteilungsstrategien: ,,Energy-aware Scheduling'' (Linux-Strategie zur Prozessorallokation -nicht zeitlichem Multiplexing!)
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
\item \textbf{Alternative:} energieintensive Prozesse verlangsamen $\rightarrow$ Regelung der CPU-Leistungsparameter
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\subsubsection{Systemglobale Energieeinsparungsmaßnahmen}
|
||||||
\subsubsection{Systemglobale
|
|
||||||
Energieeinsparungsmaßnahmen}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item Traditionelle: zu jedem Zeitpunkt Spitzen-Performanz angestrebt
|
||||||
Traditionelle Betriebssysteme: Entwurf so, dass zu jedem Zeitpunkt
|
|
||||||
Spitzen-Performanzangestrebt
|
|
||||||
\item
|
|
||||||
Beobachtungen:
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item viele Anwendungen benötigen keine Spitzen-Performanz
|
\item viele Anwendungen benötigen keine Spitzen-Performanz
|
||||||
\item viele Hardware-Komponenten verbringen Zeit in Leerlaufsituationen bzw. in Situationen, wo keine Spitzen-Performanz erforderlich
|
\item viel Hardware-Zeit in Leerlaufsituationen bzw. keine Spitzen-Performanz erforderlich
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item Konsequenz (besonders für mobile Systeme)
|
||||||
Konsequenz (besonders für mobile Systeme) :
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Hardware mit Niedrigenergiezuständen(Prozessoren und Magnetplattenlaufwerke, aber auch DRAM, Netzwerkschnittstellen, Displays, ...)
|
\item Hardware mit Niedrigenergiezuständen
|
||||||
\item somit kann Betriebssystem \textbf{Energie-Management} realisieren
|
\item Betriebssystem kann \textbf{Energie-Management} realisieren
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
|
\subsubsection{Hardwaretechnologien}
|
||||||
\paragraph{Hardwaretechnologien}
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
DPM: Dynamic Power Management
|
DPM: Dynamic Power Management
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item versetzt leerlaufende/unbenutzte Hardware-Komponenten selektiv in Zustände mit niedrigem Energieverbrauch
|
\item versetzt leerlaufende Hardware selektiv in Zustände mit niedrigem Energieverbrauch
|
||||||
\item Zustandsübergänge durch Power-Manager (in Hardware) gesteuert, dem bestimmte \emph{DPM-} Strategie (Firmware) zugrunde liegt, um gutes Verhältnis zwischen Performanz/Reaktivität und Energieeinsparung zu erzielen
|
\item Zustandsübergänge durch Power-Manager gesteuert, bestimmte \emph{DPM-}Strategie (Firmware) zugrunde, um gutes Verhältnis zwischen Performanz/Reaktivität und Energieeinsparung zu erzielen
|
||||||
|
\item bestimmt, wann und wie lange eine Hardware in Energiesparmodus
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\begin{description*}
|
||||||
|
\item[Greedy] Hardware-Komponente sofort nach Erreichen des Leerlaufs in Energiesparmodus, ,,Aufwecken'' durch neue Anforderung
|
||||||
|
\item[Time-out] Energiesparmodus erst nachdem ein definiertes Intervall im Leerlauf, ,,Aufwecken'' wie bei Greedy-Strategien
|
||||||
|
\item[Vorhersage] Energiesparmodus sofort nach Erreichen des Leerlaufs, wenn Heuristik vorhersagt,dass Kosten gerechtfertigt
|
||||||
|
\item[Stochastisch] Energiesparmodus auf Grundlage stochastischen Modells
|
||||||
|
\end{description*}
|
||||||
|
|
||||||
DVS: Dynamic Voltage Scaling
|
DVS: Dynamic Voltage Scaling
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item effizientes Verfahren zur dynamischen Regulierungvon Taktfrequenz gemeinsammit Versorgungsspannung
|
\item effizientes Verfahren zur dynamischen Regulierung von Taktfrequenz gemeinsam mit Versorgungsspannung
|
||||||
\item Nutzung quadratischer Abhängigkeitder dynamischen Leistung von Versorgungsspannung
|
\item Nutzung quadratischer Abhängigkeit der dynamischen Leistung von Versorgungsspannung
|
||||||
\item Steuerung/Strategien: Softwareunterstützungnotwendig!
|
\item Steuerung/Strategien: Softwareunterstützung notwendig
|
||||||
\end{itemize*}
|
\item Ziel: Unterstützung von DPM-Strategien durch Maßnahmen auf Ebene von Compiler, Betriebssystem und Applikationen
|
||||||
\end{itemize*}
|
\item \textbf{Betriebssystem} (prädiktives Energiemanagement)
|
||||||
|
|
||||||
Dynamisches Energiemanagement (DPM)- Strategien (Klassen) bestimmt, wann
|
|
||||||
und wie lange eine Hardware-Komponente sich in Energiesparmodusbefinden
|
|
||||||
sollte
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item kann Benutzung verschiedener Ressourcen beobachten
|
||||||
Greedy: Hardware-Komponente sofort nach Erreichen des Leerlaufs in
|
|
||||||
Energiesparmodus, ,,Aufwecken'' durch neue Anforderung
|
|
||||||
\item
|
|
||||||
Time-out: Energiesparmodus erst nachdem ein definiertes Intervall im
|
|
||||||
Leerlauf, ,,Aufwecken'' wie bei Greedy-Strategien
|
|
||||||
\item
|
|
||||||
Vorhersage: Energiesparmodus sofort nach Erreichen des Leerlaufs, wenn
|
|
||||||
Heuristik vorhersagt,dass Kosten gerechtfertigt
|
|
||||||
\item
|
|
||||||
Stochastisch: Energiesparmodus auf Grundlage eines stochastischen
|
|
||||||
Modells
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
Spannungsskalierung (DVS)
|
|
||||||
|
|
||||||
\begin{itemize*}
|
|
||||||
\item
|
|
||||||
Ziel: Unterstützung von DPM-Strategien durch Maßnahmen auf Ebene von
|
|
||||||
Compiler, Betriebssystem und Applikationen:
|
|
||||||
\begin{itemize*}
|
|
||||||
\item \textbf{Compiler} \begin{itemize*} \item kann Informationen zur Betriebssystem-Unterstützung bezüglich Spannungs-Einstellung in Anwendungs-Code einstreuen, \item damit zur Laufzeit Informationen über jeweilige Arbeitslast verfügbar \end{itemize*}
|
|
||||||
\end{itemize*}
|
|
||||||
\item
|
|
||||||
\textbf{Betriebssystem (prädiktives Energiemanagement)}
|
|
||||||
\begin{itemize*}
|
|
||||||
\item kann Benutzung verschiedener Ressourcen (Prozessor usw.) beobachten
|
|
||||||
\item kann darüber Vorhersagen tätigen
|
\item kann darüber Vorhersagen tätigen
|
||||||
\item kann notwendigen Performanzbereich bestimmen
|
\item kann notwendigen Performanzbereich bestimmen
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item \textbf{Anwendungen} können Informationen über jeweils für sie notwendige Performanz liefern
|
||||||
\textbf{Anwendungen}
|
\item $\rightarrow$ Kombination mit energieefizientem Scheduling
|
||||||
\begin{itemize*}
|
|
||||||
\item können Informationen über jeweils für sie notwendige Performanz liefern
|
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
|
||||||
$\rightarrow$ Kombination mit
|
|
||||||
energieefizientemScheduling!
|
|
||||||
\end{itemize*}
|
|
||||||
|
|
||||||
|
|
||||||
\subsection{Speichereffizienz}
|
\subsection{Speichereffizienz}
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item
|
||||||
... heißt: Auslastung des verfügbaren Speichers
|
... heißt: Auslastung des verfügbaren Speichers
|
||||||
@ -1387,12 +1210,12 @@
|
|||||||
\item
|
\item
|
||||||
Schichtendifferenzierung ( layered operating system )
|
Schichtendifferenzierung ( layered operating system )
|
||||||
\item
|
\item
|
||||||
Modularisierung (Bsp.: Linux-Kernel) \textbar{} Kernelcode \textbar{}
|
Modularisierung (Bsp.: Linux-Kernel) | Kernelcode |
|
||||||
\textbar{}
|
|
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
|
-------------------------
|
||||||
\textbar{} \textbar{} VFS \textbar{} \textbar{} IPC, Dateisystem
|
| | VFS | | IPC, Dateisystem
|
||||||
\textbar{} \textbar{} Scheduler, VMM \textbar{} \textbar{} Dispatcher,
|
| | Scheduler, VMM | | Dispatcher,
|
||||||
Gerätetreiber \textbar{}
|
Gerätetreiber |
|
||||||
\item
|
\item
|
||||||
Modularer Makrokernel:
|
Modularer Makrokernel:
|
||||||
\item
|
\item
|
||||||
@ -2257,19 +2080,19 @@
|
|||||||
\item MTTF: Mean Time to Failure ... Erwartungswert für TTF
|
\item MTTF: Mean Time to Failure ... Erwartungswert für TTF
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item
|
||||||
einige Verfügbarkeitsklassen: \textbar{} Verfügbarkeit \textbar{}
|
einige Verfügbarkeitsklassen: | Verfügbarkeit |
|
||||||
Ausfallzeit pro Jahr \textbar{} Ausfallzeit pro Woche \textbar{}
|
Ausfallzeit pro Jahr | Ausfallzeit pro Woche |
|
||||||
\textbar{} -\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
|
| ------------- |
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
|
-------------------- |
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
|
---------------------
|
||||||
\textbar{} \textbar{} 90\% \textbar{} \textgreater{} 1 Monat
|
| | 90\% | \textgreater{} 1 Monat
|
||||||
\textbar{} ca. 17 Stunden \textbar{} \textbar{} 99\% \textbar{} ca. 4
|
| ca. 17 Stunden | | 99\% | ca. 4
|
||||||
Tage \textbar{} ca. 2 Stunden \textbar{} \textbar{} 99,9\% \textbar{}
|
Tage | ca. 2 Stunden | | 99,9\% |
|
||||||
ca. 9 Stunden \textbar{} ca. 10 Minuten \textbar{} \textbar{} 99,99\%
|
ca. 9 Stunden | ca. 10 Minuten | | 99,99\%
|
||||||
\textbar{} ca. 1 Stunde \textbar{} ca. 1 Minute \textbar{} \textbar{}
|
| ca. 1 Stunde | ca. 1 Minute | |
|
||||||
99,999\% \textbar{} ca. 5 Minuten \textbar{} ca. 6 Sekunden \textbar{}
|
99,999\% | ca. 5 Minuten | ca. 6 Sekunden |
|
||||||
\textbar{} 99,9999\% \textbar{} ca. 2 Sekunden \textbar{}
|
| 99,9999\% | ca. 2 Sekunden |
|
||||||
\textless\textless{} 1 Sekunde \textbar{}
|
\textless\textless{} 1 Sekunde |
|
||||||
\item
|
\item
|
||||||
Hochverfügbarkeitsbereich (gefeierte ,,five nines'' availability)
|
Hochverfügbarkeitsbereich (gefeierte ,,five nines'' availability)
|
||||||
\item
|
\item
|
||||||
@ -2639,18 +2462,18 @@
|
|||||||
Vorgehensweise: Security Engineering
|
Vorgehensweise: Security Engineering
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
\textbar{} \textbar{} \textbar{}
|
| | |
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
|
----------------------
|
||||||
\textbar{}
|
|
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-
|
-----------------------------------------------------------------------------------------
|
||||||
\textbar{} \textbar{} Sicherheitsziele \textbar{} Welche
|
| | Sicherheitsziele | Welche
|
||||||
Sicherheitsanforderungen muss das Betriebssystem erfüllen? \textbar{}
|
Sicherheitsanforderungen muss das Betriebssystem erfüllen? |
|
||||||
\textbar{} Sicherheitspolitik \textbar{} Durch welche Strategien soll es
|
| Sicherheitspolitik | Durch welche Strategien soll es
|
||||||
diese erfüllen? ( $\rightarrow$ Regelwerk) \textbar{}
|
diese erfüllen? ( $\rightarrow$ Regelwerk) |
|
||||||
\textbar{} Sicherheitsmechanismen \textbar{} Wie implementiert das
|
| Sicherheitsmechanismen | Wie implementiert das
|
||||||
Betriebssystem seine Sicherheitspolitik? \textbar{} \textbar{}
|
Betriebssystem seine Sicherheitspolitik? | |
|
||||||
Sicherheitsarchitektur \textbar{} Wo implementiert das Betriebssystem
|
Sicherheitsarchitektur | Wo implementiert das Betriebssystem
|
||||||
seine Sicherheitsmechanismen (und deren Interaktion)? \textbar{}
|
seine Sicherheitsmechanismen (und deren Interaktion)? |
|
||||||
|
|
||||||
|
|
||||||
\subparagraph{Sicherheitspolitiken und
|
\subparagraph{Sicherheitspolitiken und
|
||||||
@ -2987,15 +2810,15 @@
|
|||||||
\paragraph{ACLs:
|
\paragraph{ACLs:
|
||||||
Linux-Implementierung}
|
Linux-Implementierung}
|
||||||
|
|
||||||
Modell einer Unix acm ... \textbar{} \textbar{} lesen \textbar{}
|
Modell einer Unix acm ... | | lesen |
|
||||||
schreiben \textbar{} ausführen \textbar{} \textbar{}
|
schreiben | ausführen | |
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
|
--------------------- |
|
||||||
-\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/-\/-\/-\/-\/- \textbar{}
|
----- | --------- |
|
||||||
-\/-\/-\/-\/-\/-\/-\/-\/- \textbar{} \textbar{} Eigentümer (,,u'')
|
--------- | | Eigentümer (,,u'')
|
||||||
\textbar{} ja \textbar{} ja \textbar{} ja \textbar{} \textbar{} Rest der
|
| ja | ja | ja | | Rest der
|
||||||
Welt (,,o'') \textbar{} ja \textbar{} nein \textbar{} ja \textbar{}
|
Welt (,,o'') | ja | nein | ja |
|
||||||
\textbar{} Gruppe (,,g'') \textbar{} ja \textbar{} nein \textbar{} ja
|
| Gruppe (,,g'') | ja | nein | ja
|
||||||
\textbar{}
|
|
|
||||||
|
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item
|
\item
|
||||||
@ -3135,7 +2958,7 @@
|
|||||||
dazu muss
|
dazu muss
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item \emph{root} bzw. zweckgebundener Nutzer Eigentümer des Druckers sein
|
\item \emph{root} bzw. zweckgebundener Nutzer Eigentümer des Druckers sein
|
||||||
\item ACL als \texttt{rw-\ -\/-\/-\ -\/-\/-} gesetzt sein
|
\item ACL als \texttt{rw-\ ---\ ---} gesetzt sein
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|
||||||
@ -3610,7 +3433,7 @@
|
|||||||
Objekte (verschiedene Systemressourcen, genutzt für Speicherung,
|
Objekte (verschiedene Systemressourcen, genutzt für Speicherung,
|
||||||
Kommunikation: Dateien, Directories, Sockets, SharedMemory usw.)
|
Kommunikation: Dateien, Directories, Sockets, SharedMemory usw.)
|
||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item haben ACLs (,,rwxrw-\/-\/-\/-'')
|
\item haben ACLs (,,rwxrw----'')
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
\item
|
\item
|
||||||
Regeln der Sicherheitspolitik, die durch den Referenzmonitor (hier
|
Regeln der Sicherheitspolitik, die durch den Referenzmonitor (hier
|
||||||
@ -4894,7 +4717,7 @@
|
|||||||
\begin{itemize*}
|
\begin{itemize*}
|
||||||
\item Anforderungsreihenfolge $t_1 = 98, 37, 124, 65$
|
\item Anforderungsreihenfolge $t_1 = 98, 37, 124, 65$
|
||||||
\item Anforderungsreihenfolge $t_2 = 183, 122, 14, 67$
|
\item Anforderungsreihenfolge $t_2 = 183, 122, 14, 67$
|
||||||
\item Zuletzt gelesener Block: 53 \textbar{} \textbar{} $a_i$ \textbar{} $d_i$ \textbar{} \textbar{} -\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/- \textbar{} -\/-\/-\/-\/- \textbar{} \textbar{} $t_1$ \textbar{} 0 \textbar{} 3 \textbar{} \textbar{} $t_2$ \textbar{} 0 \textbar{} 9 \textbar{}
|
\item Zuletzt gelesener Block: 53 | | $a_i$ | $d_i$ | | ----- | ----- | ----- | | $t_1$ | 0 | 3 | | $t_2$ | 0 | 9 |
|
||||||
%\item
|
%\item
|
||||||
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-edf.png}
|
% %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sekundärspeicherverwaltung-edf.png}
|
||||||
\end{itemize*}
|
\end{itemize*}
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user