ADD timers subsystem
This commit is contained in:
Binary file not shown.
@@ -25,6 +25,7 @@ Hier ist der Standarwert ein Nein [n], meine Einstellung ein Ja [Y].
|
||||
|
||||
\subsection{Compile also drivers which will not load}
|
||||
CONFIG\_COMPILE\_TEST [=n] \textbf{[~]}\\
|
||||
\textit{Kompilieren Sie auch Treiber, die nicht geladen werden können}\\
|
||||
Einige Treiber können auf einer anderen Plattform kompiliert werden als
|
||||
auf der, für die sie gedacht sind. Obwohl sie dort nicht geladen werden
|
||||
können (oder selbst wenn sie geladen werden können, können sie aufgrund
|
||||
@@ -34,6 +35,7 @@ trotzdem kompilieren und testen.
|
||||
|
||||
\subsection{Compile the kernel with warnings as errors}
|
||||
CONFIG\_WERROR [=n] \textbf{[Y]}\\
|
||||
\textit{Den Kernel mit Fehlermeldungen bei Warnungen kompilieren}\\
|
||||
Ein Build sollte keine Compiler-Warnungen ausgeben, dies aktiviert die
|
||||
Flags '-Werror' (für C) und '-Dwarnings' (für Rust) um diese Regel
|
||||
standardmäßig zu setzen. Bestimmte Warnungen von anderen Tools z.B. der
|
||||
@@ -45,6 +47,7 @@ um den Kernel erfolgreich zu bauen. Im Zweifelsfall sagen sie Y für Ja.
|
||||
|
||||
\subsection{Local version -- append to kernel release}
|
||||
CONFIG\_LOCALVERSION [=] \textbf{[~]}\\
|
||||
\textit{Lokale Version -- an die Kernelversion anhängen}\\
|
||||
Type: string\\
|
||||
Hängen Sie eine zusätzliche Zeichenkette an das Ende Ihrer Kernelversion
|
||||
an.\\
|
||||
@@ -75,7 +78,7 @@ Build-ID einbezogen. Wird von Distributionen verwendet, die sicherstellen
|
||||
wollen, dass es eineindeutige IDs zwischen verschiedenen Builds gibt.
|
||||
Üblicherweise brauchen wir das nicht.
|
||||
|
||||
\subsection{Kernel compression mode}
|
||||
\subsection{Kernel compression mode \( \rightarrow \)}
|
||||
Der Linux-Kernel ist eine Art selbstextrahierende, ausführbare Datei.
|
||||
Es stehen mehrere Kompressionsalgorithmen zur Verfügung, die sich in
|
||||
Effizienz, Kompressions- und Dekompressionsgeschwindigkeit unterscheiden.
|
||||
@@ -98,32 +101,36 @@ Dekompressionsgeschwindigkeit.
|
||||
\subsubsection{Bzip2}
|
||||
CONFIG\_KERNEL\_BZIP2 [=n] \textbf{[~]}\\
|
||||
Die Kompressionsrate und auch die Geschwindigkeit der ist durchschnittlich. Die Geschwindigkeit
|
||||
der Dekomprimierung ist die langsamste. Größe des Kernels ist etwa 10 \% kleiner im Vergleich zu GZIP. Es benötigt auch einen großen Speicherbereich, bei
|
||||
modernen Kerneln benötigt man zumindest 8 MB RAM oder mehr beim Booten.
|
||||
der Dekomprimierung ist die langsamste. Größe des Kernels ist etwa 10~\% kleiner
|
||||
im Vergleich zu GZIP. Es benötigt auch einen großen Speicherbereich, bei
|
||||
modernen Kerneln benötigt man zumindest 8~MB~RAM oder mehr beim Booten.
|
||||
\subsubsection{LZMA}
|
||||
CONFIG\_KERNEL\_LZMA [=n] \textbf{[~]}\\
|
||||
Dieser Kompressionsalgorthmus hat die höchste Komprimierung. Die Geschwindigkeit der Dekomprimierung liegt
|
||||
zwischen GZIP und BZIP2. Komprimierung ist die langsamste. Kernelgröße beträgt etwa 33 \% weniger als mit GZIP.
|
||||
Dieser Kompressionsalgorithmus hat die höchste Komprimierung. Die Geschwindigkeit der
|
||||
Dekomprimierung liegt zwischen GZIP und BZIP2.
|
||||
Komprimierung ist die langsamste. Kernelgröße beträgt etwa 33~\% weniger als mit GZIP.
|
||||
\subsubsection{XZ}
|
||||
CONFIG\_KERNEL\_XZ [=n] \textbf{[~]}\\
|
||||
XZ verwendet den LZMA2-Algorithmus und befehlssatzspezifische
|
||||
BCJ-Filter, die das Komprimierungsverhältnis des ausführbaren
|
||||
Codes verbessern können. Die Größe des Kernels ist mit XZ im
|
||||
Vergleich zu GZIP etwa 30 \% kleiner. Auf Architekturen, für die
|
||||
Vergleich zu GZIP etwa 30~\% kleiner. Auf Architekturen, für die
|
||||
es einen BCJ-Filter gibt (i386, x86\_64, ARM, IA-64, PowerPC und
|
||||
SPARC), erzeugt XZ einen um einige Prozent kleineren Kernel als
|
||||
einfaches LZMA.
|
||||
Die Geschwindigkeit ist in etwa die gleiche wie bei LZMA: Die Dekomprimierungsgeschwindigkeit von XZ ist besser als die von bzip2, aber schlechter als die von gzip und LZO. Die Komprimierung ist langsam.
|
||||
Die Geschwindigkeit ist in etwa die gleiche wie bei LZMA: Die Dekomprimierungsgeschwindigkeit von
|
||||
XZ ist besser als die von bzip2, aber schlechter als die von gzip und LZO.
|
||||
Die Komprimierung ist langsam.
|
||||
\subsubsection{LZO}
|
||||
CONFIG\_KERNEL\_LZO [=n] \textbf{[~]}\\
|
||||
Kompressionsrate ist die schlechteste aller anderen. Kernelgröße ist etwa 10 \% größer als GZIP.
|
||||
Kompressionsrate ist die schlechteste aller anderen. Kernelgröße ist etwa 10~\% größer als GZIP.
|
||||
Jedoch ist die Geschwindigkeit beim Komprimieren und Dekomrimieren die höchste.
|
||||
|
||||
\subsubsection{LZ4}
|
||||
CONFIG\_KERNEL\_LZ4 [=n] \textbf{[~]}\\
|
||||
LZ4 ist eine LZ77-Typ-Komprimierung mit einer festen, byte-orientierten Enkodierung.
|
||||
Siehe auch http://code.google.com/p/lz4.
|
||||
Komprimierungsverhältnis ist noch schlechter als LZO. 8 \% größere Kernelgröße als bei LZO.
|
||||
Komprimierungsverhältnis ist noch schlechter als LZO. 8~\% größere Kernelgröße als bei LZO.
|
||||
Dekomprimierung ist jedoch von der Geschwindigkeit her schneller als LZO.
|
||||
|
||||
\subsubsection{ZSTD}
|
||||
@@ -197,7 +204,7 @@ verwendet werden kann, wie z.B. SELinux (das dies für die Protokollierung der A
|
||||
von avc-Nachrichten benötigt). Die Systemaufrufüberprüfung ist auf Architekturen,
|
||||
die sie unterstützen, enthalten.
|
||||
|
||||
\subsection{IRQ subsystem}
|
||||
\subsection{IRQ subsystem \( \rightarrow \)}
|
||||
Über diese Schnittstelle kann man Funktionen und Parameter für den
|
||||
Kernelbau auswählen.
|
||||
Merkmale können entweder eingebaut, modularisiert oder ignoriert werden.
|
||||
@@ -210,12 +217,61 @@ Legt interne Zustandsinformationen über debugfs offen.
|
||||
Hauptsächlich für Entwickler und zur Fehlersuche bei schwer
|
||||
zu diagnostizierenden Interrupt-Problemen.
|
||||
|
||||
\subsection{Timers subsystem}
|
||||
\subsubsection{Timer tick handling (Idle dynticks system(tickless idle))}
|
||||
\subsection{Timers subsystem \( \rightarrow \)}
|
||||
\subsubsection{Timer tick handling \( \rightarrow \)}
|
||||
Sie müssen aus den folgenden drei Möglichkeiten eine wählen:
|
||||
\paragraph{Periodic timer ticks (constant rate, no dynticks)}
|
||||
CONFIG\_HZ\_PERIODIC [=n] \textbf{[N]}\\
|
||||
Diese Option sorgt dafür, dass der Tick periodisch mit einer konstanten Rate läuft,
|
||||
auch wenn die CPU ihn nicht braucht.
|
||||
\paragraph{Idle dynticks system (tickless idle)}
|
||||
% \\
|
||||
CONFIG\_NO\_HZ\_IDLE [=n] \textbf{[N]}\\
|
||||
Diese Option ermöglicht ein tickloses idle-System (Leerlaufsystem):
|
||||
Timer-Interrupts werden nur bei Bedarf ausgelöst, wenn das System im
|
||||
Leerlauf ist. Dies ist v.a. zum Energiesparen interessant.
|
||||
\paragraph{Full dynticks system (tickless)}
|
||||
% \\
|
||||
CONFIG\_NO\_HZ\_FULL [=y] \textbf{[Y]}\\
|
||||
Diese Option ermöglicht ein tickloses idle-System (Leerlaufsystem):
|
||||
Timer-Interrupts werden nur bei Bedarf ausgelöst, wenn das System im
|
||||
Leerlauf ist. Dies ist v.a. zum Energiesparen interessant.\\
|
||||
Wird bei Linux-Distributionen ausgewählt.
|
||||
|
||||
\subsubsection{Force user context tracking}
|
||||
CONFIG\_CONTEXT\_TRACKING\_USER\_FORCE [=n] \textbf{[N]}\\
|
||||
Die wichtigste Voraussetzung für das Funktionieren von Full-Dynticks ist die
|
||||
Unterstützung des Subsystems zur Verfolgung des Benutzerkontextes.
|
||||
Es gibt aber auch noch andere Abhängigkeiten, die erfüllt werden müssen, damit
|
||||
die vollständigen Dynticks funktionieren.\\
|
||||
Diese Option dient zum Testen, wenn eine Systemarchitektur das Backend für die
|
||||
Benutzerkontextverfolgung implementiert, aber noch nicht alle Anforderungen erfüllt,
|
||||
um die volle Dynticks-Funktion zu ermöglichen.
|
||||
Ohne die vollständigen Dynticks gibt es keine Möglichkeit,
|
||||
die Unterstützung für die Benutzerkontextverfolgung und die Teilsysteme,
|
||||
die darauf angewiesen sind, zu testen: RCU Userspace extended quiescent state
|
||||
und tickless cputime accounting. Diese Option kommt mit dem Fehlen des vollständigen
|
||||
dynticks-Subsystems zurecht, indem sie die Benutzerkontextverfolgung auf
|
||||
allen CPUs im System erzwingt.
|
||||
|
||||
Sagen Sie nur dann ja (Y), wenn Sie an der Entwicklung eines Architektur-Backends
|
||||
für die Benutzerkontextverfolgung arbeiten.
|
||||
Sagen Sie ansonsten N, da diese Option einen Overhead mit sich bringt, den Sie in
|
||||
der Praxis nicht haben wollen.
|
||||
|
||||
\subsubsection{Old Idle dynticks config}
|
||||
CONFIG\_NO\_HZ [=y] \textbf{[Y]}\\
|
||||
Dies ist der alte Konfigurationseintrag, der Dynticks im Leerlauf aktiviert.\\
|
||||
Wir behalten ihn noch eine Weile bei, um die Abwärtskompatiblität mit älteren
|
||||
Konfigurationsdateien zu gewährleisten.
|
||||
|
||||
\subsubsection{High Resolution Timer Support}
|
||||
CONFIG\_HIGH\_RES\_TIMERS [=y] \textbf{[Y]}\\
|
||||
\textit{Unterstützung von Timern mit hoher Auflösung}
|
||||
Diese Option aktiviert die Unterstützung hochauflösender Timer.
|
||||
Wenn ihre Hardware dazu nicht in der Lage ist, erhöht diese
|
||||
Option nur die Größe des Kernel-Images.
|
||||
|
||||
|
||||
|
||||
\end{document}
|
||||
|
||||
Reference in New Issue
Block a user