1406 lines
76 KiB
TeX
1406 lines
76 KiB
TeX
\section{General setup \texorpdfstring{$\rightarrow$}{->}}
|
|
|
|
\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
|
|
fehlender Hardware-Unterstützung nicht verwendet werden), möchten
|
|
Entwickler, im Gegensatz zu Distributoren, solche Treiber vielleicht
|
|
trotzdem kompilieren und testen.
|
|
|
|
\subsection{Compile the kernel with warnings as errors}
|
|
CONFIG\_WERROR \colorbox{yellow!80}{[=n] \textbf{[Y]}}\\
|
|
\textit{Den Kernel mit Fehlermeldungen bei Warnungen kompilieren}\\
|
|
Ein Build sollte keine Compiler-Warnungen ausgeben, dies aktiviert die
|
|
Flags \texttt{-Werror} (für C) und \texttt{-Dwarnings} (für Rust) um diese Regel
|
|
standardmäßig zu setzen. Bestimmte Warnungen von anderen Tools z.\,B. der
|
|
Linker könnte mit dieser Option Fehler generieren. Deaktivieren ist
|
|
sinnvoll, wenn Sie einen neuen (oder sehr alten) Compiler bzw. Linker
|
|
mit seltenen, ungewöhnlichen Warnungen haben. Haben Sie auf Ihrer
|
|
Architektur Probleme, dann müssen Sie diese Konfiguration deaktivieren,
|
|
um den Kernel erfolgreich zu bauen. Im Zweifelsfall sagen sie Y für Ja.
|
|
\\\begin{scriptsize}
|
|
Für den Laptop wird der Kernel ohne Warnungen kompiliert, ansonsten wird ein Fehler generiert.
|
|
\end{scriptsize}
|
|
|
|
\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.\\
|
|
Dies wird angezeigt, wenn Sie z.\,B. \texttt{uname} eingeben. Die hier
|
|
angegebene Zeichenfolge wird an den Inhalt von einem Dateinamen mit
|
|
\texttt{localverion*} als Objekt und im Quellbaum, in dieser Reihenfolge
|
|
angezeigt. Die Zeichenkette darf maximal 64 Zeichen lang sein.
|
|
|
|
%1.4
|
|
\subsection{Automatically append version information to the version string}
|
|
CONFIG\_LOCALVERSION\_AUTO [=y] \textbf{[Y]}\\
|
|
Dies versucht automatisch festzustellen, ob der aktuelle Baum ein
|
|
Release-Tree ist, indem es nach \textbf{Git}-Tags sucht, die zur aktuellen
|
|
Top-of-Tree"=Revision gehören.\\
|
|
Eine Zeichenkette des Formats \texttt{-gxxxxxxxx} wird der lokalen Version
|
|
hinzugefügt, wenn ein git-basierter Baum gefunden wird. Die so erzeugte
|
|
Zeichenkette wird nach allen passenden \glqq localversion*\grqq -Dateien
|
|
und nach dem in CONFIG\_LOCALVERSION eingestellten Wert angehängt. (Die hier
|
|
tatsächlich verwendete Zeichenkette sind die ersten 12~Zeichen, die durch
|
|
die Ausführung des Befehls erzeugt werden:\\
|
|
\indent\texttt{\$ git rev-parse --verify HEAD}\\
|
|
der innerhalb des Skripts \glqq scripts/setlocalversion\grqq{} ausgeführt wird.)
|
|
\subsection{Build ID Salt}
|
|
CONFIG\_BUILD\_SALT [=] \textbf{[~]}\\
|
|
Type: string\\
|
|
Dies wird verwendet, um die Binaries und ihre Debug-Infos zu verknüpfen.
|
|
Wenn diese Option gesetzt ist, dann wird dieser Wert in die Berechnung der
|
|
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 \texorpdfstring{$\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.
|
|
Die Komprimierungsgeschwindigkeit ist nur bei der Erstellung eines Kernels
|
|
relevant. Die Dekomprimierungsgeschwindigkeit ist bei jedem Systemstart
|
|
von Bedeutung. (Eine ältere Version dieser Funktionalität (nur bzip2)
|
|
für 2.4 wurde von Christian Ludwig bereitgestellt)
|
|
Hohe Komprimierungsoptionen sind vor allem für Benutzer nützlich, die
|
|
wenig Festplattenplatz zur Verfügung haben (embedded systems), für die
|
|
aber die Ram-Größe weniger wichtig ist.\\
|
|
Überblick: Gzip werden von den älteren Kernelversionen unterstützt,\\
|
|
Arch Linux (since Linux/x86 5.9.0) Standard: ZSTD (former: XZ since 4.14.4, predecessor GZIP,XZ)\\
|
|
Debian 11.6: XZ\\
|
|
@TODO Weitere Linux Distributionen
|
|
\subsubsection{Gzip}
|
|
CONFIG\_KERNEL\_GZIP [=n] \textbf{[~]}\\
|
|
Die alte und bewährte gzip-Kompression. Sie bietet ein gutes
|
|
Gleichgewicht zwischen Kompressionsrate und
|
|
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 $\qty{10}{\percent}$ 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 Kompressionsalgorithmus hat die höchste Komprimierung. Die Geschwindigkeit der
|
|
Dekomprimierung liegt zwischen GZIP und BZIP2.
|
|
Komprimierung ist die langsamste. Kernelgröße beträgt etwa $\qty{33}{\percent}$
|
|
weniger als mit GZIP.
|
|
|
|
\subsubsection{XZ}
|
|
CONFIG\_KERNEL\_XZ [=n] \textbf{[~]}\\
|
|
XZ verwendet den LZMA2-Algorithmus und befehlssatzspezifische
|
|
BCJ-Filter, die das Komprimierungs\-verhältnis des ausführbaren
|
|
Codes verbessern können. Die Größe des Kernels ist mit XZ im
|
|
Vergleich zu GZIP etwa $\qty{30}{\percent}$ 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.
|
|
|
|
%1.6.5
|
|
\subsubsection{LZO}
|
|
CONFIG\_KERNEL\_LZO [=n] \textbf{[~]}\\
|
|
Kompressionsrate ist die schlechteste aller anderen. Kernelgröße ist etwa $\qty{10}{\percent}$
|
|
größer als GZIP.
|
|
Jedoch ist die Geschwindigkeit beim Komprimieren und Dekomprimieren die höchste.
|
|
|
|
\subsubsection{LZ4}
|
|
CONFIG\_KERNEL\_LZ4 [=n] \textbf{[~]}\\
|
|
LZ4 ist eine LZ77-Typ-Komprimierung mit einer festen, byte"=orientierten Enkodierung.\\
|
|
Siehe auch \url{http://code.google.com/p/lz4}.\\
|
|
Komprimierungsverhältnis ist noch schlechter als LZO. $\qty{8}{\percent}$ größere Kernelgröße als bei LZO.
|
|
Dekomprimierung ist jedoch von der Geschwindigkeit her schneller als LZO.
|
|
|
|
\subsubsection{ZSTD}
|
|
CONFIG\_KERNEL\_ZSTD [=y] \textbf{[Y]}\\
|
|
ZSTD ist ein Komprimierungsalgorithmus, der auf eine Zwischenkomprimierung
|
|
mit schneller Dekomprimierungsgeschwindigkeit abzielt. Er
|
|
komprimiert besser als GZIP und dekomprimiert etwa so schnell wie
|
|
LZO, ist aber langsamer als LZ4. Sie benötigen mindestens
|
|
192~KB~RAM oder mehr zum Booten. Das Kommandozeilenprogramm \texttt{zstd}
|
|
ist für die Komprimierung erforderlich.
|
|
|
|
\subsection{Default init path}
|
|
CONFIG\_DEFAULT\_INIT [=] \textbf{[~]}\\
|
|
Diese Option legt den Standard"=Init"=Pfad für das System fest,
|
|
wenn in der Kernel-Befehlszeile keine solche \texttt{init=}"=Option übergeben wird.
|
|
Wenn der angeforderte Pfad nicht vorhanden ist, wird trotzdem versucht,
|
|
weitere Orte zu finden (z.\,B. /sbin/init usw.). Wenn dieser Pfad leer ist,
|
|
wird einfach die Fallback-Liste verwendet, wenn \texttt{init=} nicht übergeben wird.
|
|
|
|
\subsection{Default hostname}
|
|
CONFIG\_DEFAULT\_HOSTNAME \colorbox{yellow!80}{[=archlinux]~\textbf{[=orange]}}\\
|
|
Diese Option legt den Standard-Hostnamen des Systems fest,
|
|
noch bevor der Userspace das Kommando sethostname(2) aufruft.
|
|
Der Kernel verwendet hier traditionell ''(none)'', Sie möchten
|
|
vielleicht eine andere Voreinstellung verwenden, um ein minimales
|
|
System mit weniger Konfiguration benutzbar zu machen.
|
|
|
|
\subsection{System V IPC}
|
|
CONFIG\_SYSVIPC [=y] \textbf{[Y]}\\
|
|
Die Inter-Prozess-Kommunikation IPC ist eine Zusammenstellung
|
|
aus Bibliotheksfunktionen (libraries) und Systemaufrufen die Prozesse (laufende Programme)
|
|
synchronisiert und Daten untereinander austauschen kann. Generell ist das eine gute Sache,
|
|
einige Programme würden auch nicht funktionieren wenn Sie hier kein Y (ja) setzen.
|
|
|
|
%1.10
|
|
\subsection{POSIX Message Queues}
|
|
CONFIG\_POSIX\_MQUEUE [=y] \textbf{[Y]}\\
|
|
Die POSIX-Variante der Nachrichtenwarteschlangen (message queues) ist ein Teil der IPC.
|
|
In POSIX"=Nachrichtenwarteschlangen hat jede Nachricht eine Priorität, die über die Reihenfolge
|
|
des Empfangs durch einen Prozess entscheidet. Wenn Sie Programme kompilieren und ausführen wollen,
|
|
die z.\,B. für Solaris geschrieben wurden und die POSIX"=Warteschlangen
|
|
(Funktionen \texttt{mq\_$\ast$}) verwenden, sagen Sie hier Y.
|
|
POSIX"=Nachrichtenwarteschlangen sind via Dateisystem als \glqq mqueue\grqq{} sichtbar und können irgendwo
|
|
eingehängt werden, wenn Sie Dateisystemoperationen auf Nachrichtenwarteschlangen durchführen wollen.
|
|
|
|
\subsection{General notification queue}
|
|
CONFIG\_WATCH\_QUEUE [=y] \textbf{[Y]}\\
|
|
Dies ist eine allgemeine Benachrichtigungswarteschlange für den Kernel,
|
|
um Ereignisse an den Userspace weiterzuleiten, indem sie in Pipes gesplittet werden.
|
|
Sie kann in Verbindung mit Watches für Schlüssel-/Schlüsseländerungsbenachrichtigungen (key/keyring) und
|
|
Gerätebenachrichtigungen verwendet werden.\\
|
|
Bemerkung: Bei Debian Bullseye ist dies nicht gesetzt (N).
|
|
|
|
\subsection{Enable process\_vm\_readv/writev\ syscalls}
|
|
CONFIG\_CROSS\_MEMORY\_ATTACH [=y] \textbf{[Y]}\\
|
|
Die Aktivierung dieser Option fügt die Systemaufrufe process\_vm\_readv und
|
|
process\_vm\_writev hinzu, die es einem Prozess mit den richtigen Rechten ermöglichen,
|
|
direkt aus dem Adressraum eines anderen Prozesses zu lesen oder in diesen zu schreiben.
|
|
Weitere Einzelheiten finden Sie in der Manpage.
|
|
|
|
\subsection{uselib syscall (for libc5 and earlier)}
|
|
CONFIG\_USELIB [=n] \textbf{[N]}\\
|
|
Diese Option schaltet den uselib-Systemaufruf ein, der im dynamic"=Linker von libc5 und früher verwendet wird.
|
|
Das aktuelle glibc verwendet diesen Systemaufruf nicht mehr, deshalb kann man diese Option
|
|
ausschalten wenn sie
|
|
keine Programme mehr verwenden, die auf libc5 (oder früher) compiliert wurden.\\
|
|
Bemerkung: Debian Bullseye verwendet dies noch (Y).
|
|
|
|
\subsection{Auditing support}
|
|
CONFIG\_AUDIT [=y] \textbf{[Y]}\\
|
|
Aktivieren Sie eine Überwachungsinfrastruktur, die mit einem anderen Kernel-Subsystem
|
|
verwendet werden kann, wie z.\,B. SELinux (das dies für die Protokollierung der Ausgabe
|
|
von avc-Nachrichten benötigt). Die Systemaufrufüberprüfung ist auf Architekturen,
|
|
die sie unterstützen, enthalten.
|
|
|
|
\subsection{IRQ subsystem \texorpdfstring{$\rightarrow$}{->}}
|
|
Über diese Schnittstelle kann man Funktionen und Parameter für den
|
|
Kernelbau auswählen.
|
|
Merkmale können entweder eingebaut, modularisiert oder ignoriert werden.
|
|
Parameter müssen als dezimale oder hexadezimale Zahlen oder als Text eingegeben
|
|
werden.
|
|
|
|
\subsubsection{Expose irq internals in debugfs}
|
|
CONFIG\_GENERIC\_IRQ\_DEBUGFS [=n] \textbf{[N]}\\
|
|
Legt interne Zustandsinformationen über debugfs offen.
|
|
Hauptsächlich für Entwickler und zur Fehlersuche bei schwer
|
|
zu diagnostizierenden Interrupt-Problemen.
|
|
|
|
\subsection{Timers subsystem \texorpdfstring{$\rightarrow$}{->}}
|
|
\subsubsection{Timer tick handling \texorpdfstring{$\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 \colorbox{yellow!80}{[=y] \textbf{[N]}}\\*
|
|
\textit{Alte Leerlauf-Dynticks-Konfiguration}\\
|
|
Dies ist der alte Konfigurationseintrag, der Dynticks im Leerlauf aktiviert.
|
|
\sout{Wir behalten ihn noch eine Weile bei, um die Abwärtskompatiblität mit älteren
|
|
Konfigurations\-dateien zu gewähr\-leisten.}
|
|
\\\begin{scriptsize}
|
|
Alte Dynticks-Konfiguration wird nicht mehr unterstützt.
|
|
\end{scriptsize}
|
|
|
|
\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.
|
|
|
|
\subsubsection{Clocksource watchdog maximum allowable skew}
|
|
CONFIG\_CLOCKSOURCE\_WATCHDOG\_MAX\_SKEW\_US [=100] \textbf{[100]}\\
|
|
\textit{Maximal zulässige Abweichung der Watchdog-Taktquelle}\\
|
|
Geben Sie den maximal zulässigen Wert für den Watchdog"=Versatz
|
|
in Mikrosekunden an, bevor die Clocksource als instabil gemeldet wird.
|
|
Der Standardwert basiert auf einem Watchdog-Intervall von einer halben
|
|
Sekunde und der maximalen Frequenzdrift von NTP von 500 Teilen pro Million.
|
|
Wenn die Clocksource gut genug für NTP ist, ist sie auch gut genug
|
|
für den Watchdog der Clocksource!\\
|
|
Bereich (Range): 50 -- 1000
|
|
|
|
\subsection{BPF subsystem \texorpdfstring{$\rightarrow$}{->}}
|
|
Berkeley Packet Filter, Firewall-Filtertechnik im Kernel
|
|
|
|
\subsubsection{Enable bpf() system call}
|
|
CONFIG\_BPF\_SYSCALL [=y] \textbf{[Y]}\\
|
|
Aktivieren Sie den Systemaufruf bpf(), der es ermöglicht,
|
|
BPF-Programme und -Maps über Dateideskriptoren zu manipulieren.
|
|
|
|
\subsubsection{Enable BPF Just In Time compiler}
|
|
CONFIG\_BPF\_JIT [=y] \textbf{[Y]}\\
|
|
BPF-Programme werden normalerweise von einem BPF-Interpreter verarbeitet.
|
|
Diese Option ermöglicht es dem Kernel, nativen Code zu erzeugen,
|
|
wenn ein Programm in den Kernel geladen wird. Dadurch wird die Verarbeitung
|
|
von BPF"=Programmen erheblich beschleunigt.\\
|
|
Beachten Sie, dass ein Administrator diese Funktion durch Ändern aktivieren sollte:\\[0.5em]
|
|
\indent\texttt{/proc/sys/net/core/bpf\_jit\_enable}\\
|
|
\indent\texttt{/proc/sys/net/core/bpf\_jit\_harden (optional)}\\
|
|
\indent\texttt{/proc/sys/net/core/bpf\_jit\_kallsyms (optional)}
|
|
|
|
\paragraph{Permanently enable BPF JIT and remove BPF interpreter}$~$\\
|
|
CONFIG\_BPF\_JIT\_ALWAYS\_ON [=y] \textbf{[Y]}\\
|
|
Aktiviert BPF JIT und entfernt den BPF"=Interpreter um spekulative Ausführungen
|
|
von BPF-An\-wei\-sun\-gen durch den Interpreter zu verhindern.
|
|
Wenn CONFIG\_BPF\_JIT\_ALWAYS\_ON eingeschaltet ist, dann wird
|
|
\texttt{/proc/sys/net/core/bpf\_jit\_enable} permanent auf 1 gesetzt, alle
|
|
Versuche diese Einstellung auf andere Werte zu legen wird mit einem Fehler
|
|
zurückgewiesen.
|
|
\subsubsection{Disable unprivileged BPF by default}
|
|
CONFIG\_BPF\_UNPRIV\_DEFAULT\_OFF [=y] \textbf{[Y]}\\
|
|
Deaktiviert die unprivilegierte BPF standardmäßig, indem der entsprechende Eintrag\\
|
|
\texttt{/proc/sys/kernel/unprivileged\_bpf\_disabled} auf 2 gesetzt wird.
|
|
Ein Administrator kann sie immer noch wieder aktivieren,
|
|
indem er sie später auf 0 setzt, oder sie dauerhaft deaktiviert, indem
|
|
er sie auf 1 setzt (von wo aus kein weiterer Übergang auf 0 mehr möglich ist).\\
|
|
Unprivilegierte BPF könnte verwendet werden, um bestimmte potenzielle Seitenkanalschwachstellen
|
|
für spekulative Ausführung auf nicht gemilderter betroffener Hardware auszunutzen.
|
|
Wenn Sie unsicher sind, wie Sie diese Frage beantworten sollen, antworten Sie mit Y.
|
|
\subsubsection{Preload BPF file system with kernel specific program
|
|
and map iterators \texorpdfstring{$\rightarrow$}{->}}
|
|
BPF\_PRELOAD [=n] \textbf{[N]}\\
|
|
Dadurch wird ein Kernelmodul mit mehreren eingebetteten BPF"=Programmen erstellt,
|
|
die als für den Menschen lesbare Dateien in den BPF-FS"=Einhängepunkt
|
|
eingefügt werden, was bei der Fehlersuche und der Untersuchung von BPF"=Programmen
|
|
und -Maps nützlich ist.
|
|
\paragraph{bpf\_preload kernel module\\} $~$ \\
|
|
\textit{Dies ist nur sichtbar wenn der übergeordnete Punkt aktiviert ist.}\\
|
|
CONFIG\_BPF\_PRELOAD\_UMD [=m] \textbf{[~]}\\
|
|
Dadurch wird ein Kernelmodul mit mehreren eingebetteten BPF-Programmen
|
|
erstellt, die als für den Menschen lesbare Dateien in den BPF-FS"=Einhängepunkt eingefügt werden,
|
|
was bei der Fehlersuche und der Untersuchung von BPF-Programmen und -Maps nützlich ist.
|
|
\subsubsection{Enable BPF LSM Instrumentation}
|
|
CONFIG\_BPF\_LSM [=y] \textbf{[Y]}\\
|
|
Ermöglicht die Instrumentierung der Sicherheitshaken mit BPF-Programmen zur Implementierung dynamischer
|
|
MAC- und Prüfungsrichtlinien. Wenn Sie unsicher sind, wie Sie diese Frage beantworten
|
|
sollten, antworten Sie mit N.
|
|
\subsection{Preemption Model (Preemptible Kernel (Low-Latency Desktop)) \texorpdfstring{$\rightarrow$}{->}}
|
|
Eingestellt auf : Low-Latency, d.\,h. nur kleine Verzögerungen beim Modell des Multitaskings.
|
|
Es gibt drei Einstellungen:
|
|
\subsubsection{No Forced Preemption (Server)}
|
|
CONFIG\_PREEMPT\_NONE [=n] \textbf{[N]}\\
|
|
Das war das traditionelle Linux Modell der Unterbrechungen, das sich auf den Durchsatz konzentrierte.
|
|
Wird vor allem für den Server-Einsatz verwendet. Es gibt durchaus gute Performance für die Latenz, jedoch
|
|
keine Garantie dafür und es kann zu zufälligen, längeren Verzögerungszeiten kommen.
|
|
|
|
Für einen Serverbetrieb wird diese Einstellung empfohlen, damit der maximale Durchsatz an Rechenleistung
|
|
entsteht.
|
|
\subsubsection{Voluntary Kernel Preemption (Desktop)}
|
|
CONFIG\_PREEMPT\_VOLUNTARY \colorbox{yellow!80}{[=n] \textbf{[Y]}}\\
|
|
Diese Einstellung reduziert die Latenz des Kernels durch zusätzliche \glqq explizite Unterbrechungspunkte\glqq{}
|
|
im Kernel.
|
|
Diese neuen Unterbrechungspunkte wurden ausgewählt, um die maximale Latenz beim neuerlichen Zuordnen
|
|
des Schedulers zu reduzieren und dadurch schnelle Reaktionszeiten der Applikationen zu gewährleisten. --
|
|
Auf Kosten eines geringeren Durchsatzes wird dies erreicht.
|
|
\subsubsection{Preemptible Kernel (Low-Latency Desktop)}
|
|
CONFIG\_PREEMPT \colorbox{yellow!80}{[=y] \textbf{[N]}}\\
|
|
Bei dieser Einstellung wird die Latenz des Kernels weiter erniedrigt indem der gesamte Code des Kernels
|
|
(keine kritischen, geschützten Bereiche) unterbrechbar gemacht wird. Dadurch wird ein reibungsloses
|
|
Arbeiten mit Applikationen aus Nutzersicht erreicht, sogar unter Volllast.
|
|
Wähle diese Einstellung, wenn man einen Desktop oder ein Embedded-System mit einer Latenz im
|
|
Millisekundenbereich möchte. Natürlich geht diese Einstellung mit einem leicht geringerem Durchsatz an
|
|
Rechenleistung einher.
|
|
\subsection{Preemtion behaviour defined on boot}
|
|
CONFIG\_PREEMPT\_DYNAMIC [=y] \textbf{[Y]}\\
|
|
Diese Option ermöglicht es, das Präemptionsmodell über den
|
|
Kernel-Kommandozeilenparameter zu definieren und damit das
|
|
während der Kompilierung definierte Standard"=Präemptionsmodell
|
|
außer Kraft zu setzen.
|
|
Diese Funktion ist vor allem für Linux-Distributionen
|
|
interessant, die eine vorgefertigte Kernel"=Binärdatei
|
|
bereitstellen, um die Anzahl der angebotenen Kernel"=Varianten
|
|
zu reduzieren und dennoch verschiedene Anwendungsfälle zu
|
|
ermöglichen.
|
|
|
|
Der Laufzeit-Overhead ist vernachlässigbar, wenn
|
|
HAVE\_STATIC\_CALL\_INLINE aktiviert ist, aber wenn Laufzeit-Patching
|
|
für die spezifische Architektur nicht verfügbar ist,
|
|
sollte der potenzielle Overhead in Betracht gezogen werden.
|
|
Interessant wird es, wenn derselbe vorgefertigte Kernel
|
|
sowohl für Server- als auch für Desktop-Workloads verwendet
|
|
werden soll.
|
|
\subsection{Core Scheduling for SMT}
|
|
CONFIG\_SCHED\_CORE [=y] \textbf{[Y]}\\
|
|
Kern-Scheduling für SMT
|
|
|
|
Diese Option ermöglicht Core Scheduling, ein Mittel zur
|
|
koordinierten Auswahl von Aufgaben zwischen SMT-Geschwistern.
|
|
Wenn diese Option aktiviert ist -- siehe prctl
|
|
(PR\_SCHED\_CORE)
|
|
-- stellt die Aufgabenauswahl sicher, dass alle SMT"=Geschwister
|
|
eine Aufgabe aus der gleichen \glqq Kerngruppe\grqq{} ausführen und
|
|
den Leerlauf erzwingen, wenn keine passende Aufgabe gefunden
|
|
wird.
|
|
Diese Funktion wird unter anderem verwendet:
|
|
\begin{itemize}
|
|
\item[-] Entschärfung einiger (nicht aller) SMT-Seitenkanäle;
|
|
\item[-] Begrenzung der SMT-Interferenz zur Verbesserung des Determinismus und/oder der Leistung.
|
|
\end{itemize}
|
|
SCHED\_CORE ist standardmäßig deaktiviert. Wenn es aktiviert und unbenutzt ist, was
|
|
bei Linux-Distributionen wahrscheinlich der Fall ist,
|
|
sollte es keine messbaren Auswirkungen auf die Leistung
|
|
haben.
|
|
% 1.21 Extensible Scheduling Class (since 6.11)
|
|
\subsection{Extensible Scheduling Class {\tiny since 6.12}}
|
|
CONFIG\_SCHED\_CLASS\_EXT [=y] \textbf{[Y]}\\
|
|
Diese Option aktiviert eine neue Scheduler-Klasse sched\_ext (SCX), die es ermöglicht,
|
|
dass Scheduling-Richtlinien
|
|
als BPF-Programme implementiert werden können, um Folgendes zu erreichen:
|
|
\begin{itemize}
|
|
\item [-] Einfaches Experimentieren und Erforschen:
|
|
Ermöglicht die schnelle Iteration neuer Zeitplanungsrichtlinien.
|
|
\item [-] Anpassungsfähigkeit: Erstellung von anwendungsspezifischen Schedulern,
|
|
die Richtlinien implementieren, die für allgemeine Scheduler nicht anwendbar sind.
|
|
\item [-] Schnelle Scheduler-Implementierungen: Unterbrechungsfreie Auslagerung von Planungsrichtlinien
|
|
in Produktionsumgebungen.
|
|
\end{itemize}
|
|
sched\_ext nutzt die BPF-Funktion struct\_ops,
|
|
um eine Struktur zu definieren,
|
|
die Funktionsaufrufe und
|
|
Flags an BPF-Programme exportiert, die Zeitplanungsrichtlinien implementieren möchten.\\
|
|
Die struct\_ops-Struktur, die von
|
|
sched\_ext exportierte Struktur heißt struct sched\_ext\_ops und ist konzeptionell ähnlich wie
|
|
struct sched\_class.
|
|
|
|
Für weitere Informationen:\\
|
|
Dokumentation/scheduler/sched-ext.rst\\
|
|
\href{https://github.com/sched-ext/scx}{https://github.com/sched-ext/scx}\\[1em]
|
|
\begin{small}
|
|
\textit{
|
|
This option enables a new scheduler class sched\_ext (SCX), which
|
|
allows scheduling policies to be implemented as BPF programs to
|
|
achieve the following:
|
|
\begin{itemize}
|
|
\item[-] Ease of experimentation and exploration: Enabling rapid
|
|
iteration of new scheduling policies.
|
|
\item[-] Customization: Building application-specific schedulers which
|
|
implement policies that are not applicable to general-purpose schedulers.
|
|
\item[-] Rapid scheduler deployments: Non-disruptive swap outs of
|
|
scheduling policies in production environments.
|
|
\end{itemize}
|
|
sched\_ext leverages BPF struct\_ops feature to define a structure
|
|
which exports function callbacks and flags to BPF programs that
|
|
wish to implement scheduling policies. The struct\_ops structure
|
|
exported by sched\_ext is struct sched\_ext\_ops, and is conceptually
|
|
similar to struct sched\_class.}
|
|
\end{small}
|
|
\subsection{CPU/Task time and stats accounting \texorpdfstring{$\rightarrow$}{->}}
|
|
|
|
\subsubsection{Cputime accounting (Full dynticks CPU time accounting) \texorpdfstring{$\rightarrow$}{->}}
|
|
\paragraph{Full dynticks CPU time accounting} $~$\\
|
|
CONFIG\_VIRT\_CPU\_ACCOUNTING\_GEN [=y] \textbf{[Y]}\\*
|
|
Wählen Sie diese Option, um die Berechnung der Task- und CPU-Zeit auf
|
|
Full"=Dynticks"=Systemen zu aktivieren.
|
|
Diese Berechnung wird durch die Überwachung aller Kernel-Benutzer-Grenzen mithilfe des
|
|
Kontextverfolgungs-Subsystems implementiert.
|
|
Die Berechnung erfolgt daher auf Kosten eines erheblichen Overheads.\\
|
|
Im Moment ist dies nur sinnvoll, wenn Sie an der Entwicklung des vollständigen
|
|
Dynticks-Subsystems arbeiten.
|
|
|
|
\subsubsection{Fine granularity task level IRQ time accounting}
|
|
CONFIG\_IRQ\_TIME\_ACCOUNTING [=y] \textbf{[Y]}\\
|
|
Wählen Sie diese Option aus, um eine fein granulare Berechnung der
|
|
Task-Irq-Zeit zu aktivieren.
|
|
Dies geschieht durch das Lesen eines Zeitstempels bei jedem Übergang
|
|
zwischen dem softirq- und dem hardirq"=Zustand, so dass es zu geringen
|
|
Leistungseinbußen kommen kann.\\
|
|
Im Zweifelsfall sagen Sie hier N für Nein.
|
|
|
|
\subsubsection{BSD Process Accounting}
|
|
CONFIG\_BSD\_PROCESS\_ACCT [=y] \textbf{[Y]}\\
|
|
Wenn Sie hier Y (für Ja) angeben, kann ein Programm auf Benutzerebene den Kernel
|
|
(über einen speziellen Systemaufruf) anweisen, Prozessabrechnungsinformationen
|
|
in eine Datei zu schreiben: Jedes Mal, wenn ein Prozess beendet wird, werden
|
|
Informationen über diesen Prozess vom Kernel an die Datei angehängt.
|
|
Die Informationen beinhalten Dinge wie die Erstellungszeit, den besitzenden
|
|
Benutzer, den Befehlsnamen, den Speicherverbrauch, das kontrollierende Terminal
|
|
usw. (die vollständige Liste kann in der acct-Struktur in
|
|
\textless{}file:include/linux/acct.h\textgreater{} gefunden werden).
|
|
Es obliegt dem Programm auf Benutzerebene, nützliche Dinge mit diesen
|
|
Informationen zu tun. Dies ist im Allgemeinen eine gute Idee, also sagen
|
|
Sie Y für Ja.
|
|
|
|
\paragraph{BSD Process Accounting version 3 file format} $~$\\
|
|
CONFIG\_BSD\_PROCESS\_ACCT\_V3 [=y] \textbf{[Y]}\\
|
|
Wenn Sie hier Y (für Ja) angeben, werden die Prozessabrechnungsinformationen
|
|
in ein neues Dateiformat geschrieben, das auch die Prozess-IDs der einzelnen
|
|
Prozesse und ihrer Eltern protokolliert. Beachten Sie, dass dieses
|
|
Dateiformat nicht mit den früheren v0/v1/v2-Dateiformaten kompatibel ist,
|
|
so dass Sie aktualisierte Werkzeuge für die Verarbeitung benötigen.
|
|
Eine vorläufige Version dieser Werkzeuge ist unter
|
|
\url{http://www.gnu.org/software/acct/} verfügbar.
|
|
|
|
\subsubsection{Export task/process statistics through netlink}
|
|
CONFIG\_TASKSTATS [=y] \textbf{[Y]}\\
|
|
Export ausgewählter Statistiken für Aufgaben/Prozesse über die generische
|
|
Netlink-Schnittstelle. Im Gegensatz zur BSD-Prozessabrechnung sind die
|
|
Statistiken während der Lebensdauer von Auf\-gaben/Pro\-zes\-sen als Antwort auf
|
|
Befehle verfügbar. Wie BSD-Accounting werden sie beim Beenden von Tasks in
|
|
den Benutzerbereich gesendet.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Enable per-task delay accounting} $~$\\
|
|
CONFIG\_TASK\_DELAY\_ACCT [=y] \textbf{[Y]}\\
|
|
Sammeln Sie Informationen über die Zeit, die eine Task für das Warten auf
|
|
Systemressourcen wie CPU, synchrone Block-E/A-Abwicklung und Auslagerung
|
|
von Seiten aufwendet. Solche Statistiken können bei der Festlegung der
|
|
Prioritäten eines Tasks im Verhältnis zu anderen Tasks für CPU-, IO-,
|
|
RSS-Limits usw. helfen.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Enable extended accounting over taskstats}$~$\\
|
|
CONFIG\_TASK\_XACCT [=y] \textbf{[Y]}\\
|
|
Sammeln von erweiterten Task-Accounting-Daten und Senden der Daten an
|
|
das Userland zur Verarbeitung über die Taskstats-Schnittstelle.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subparagraph{Enable per-task storage I/O accounting}$~$\\
|
|
CONFIG\_TASK\_IO\_ACCOUNTING [=y] \textbf{[Y]}\\
|
|
Sammeln von Informationen über die Anzahl
|
|
der Bytes an Speicher-E/A, die dieser Task verursacht hat.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{Pressure stall information tracking}
|
|
CONFIG\_PSI [=y] \textbf{[Y]}\\
|
|
Sammeln Sie Metriken, die anzeigen, wie überlastet die CPU-, Speicher-
|
|
und IO-Ka\-pa\-zi\-tät im System sind.
|
|
|
|
Wenn Sie hier Y angeben, erstellt der Kernel /proc/pressure/ mit die
|
|
Druckstatistikdateien cpu, memory und io. Diese zeigen den Anteil der
|
|
Walltime an, in dem einige oder alle Tasks im System aufgrund der
|
|
Beanspruchung der jeweiligen Ressource verzögert sind.
|
|
|
|
In Kerneln mit cgroup-Unterstützung verfügen cgroups (nur cgroup2) über
|
|
cpu.pressure-,\\*
|
|
memory.pressure- und io.pressure-Dateien, die nur die
|
|
Druckstaus für die gruppierten Aufgaben zusammenfassen.\\
|
|
Weitere Einzelheiten finden Sie unter Documentation/accounting/psi.rst.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Require boot parameter to enable pressure stall information tracking} $~$\\
|
|
CONFIG\_PSI\_DEFAULT\_DISABLED [=n] \textbf{[N]}\\
|
|
Wenn diese Option gesetzt ist, ist die Verfolgung von Druck\-stau\-informationen
|
|
standardmäßig deaktiviert, kann aber durch die Übergabe von psi=1 auf der
|
|
Kernel-Befehlszeile beim Booten aktiviert werden.\\
|
|
Diese Funktion fügt dem Task-Wakeup- und Sleep-Pfad des Schedulers etwas Code hinzu.
|
|
Der Overhead ist zu gering, um gängige planungsintensive Arbeitslasten in der Praxis
|
|
zu beeinträchtigen (z.\,B. Web\-server, Memcache), aber es zeigt sich in künstlichen
|
|
Scheduler-Stresstests, wie z.\,B. Hackbench.\\
|
|
Wenn Sie paranoid sind und nicht sicher, wofür der Kernel verwendet wird,
|
|
sagen Sie Y für Ja.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsection{CPU isolation}
|
|
CONFIG\_CPU\_ISOLATION [=y] \textbf{[Y]}\\
|
|
Stellen Sie sicher, dass CPUs, auf denen kritische Aufgaben laufen,
|
|
nicht durch irgendwelche \glqq Störquellen\grqq{} wie ungebundene Workqueues, Timers,
|
|
kthreads usw. gestört werden.\\
|
|
Ungebundene Aufgaben werden auf Housekeeping"=CPUs verlagert.
|
|
Dies wird durch den Boot-Parameter \texttt{isolcpus=} gesteuert.\\
|
|
Sagen Sie Y für ja, wenn Sie unsicher sind.
|
|
|
|
\subsection{RCU Subsystem \texorpdfstring{$\rightarrow$}{->}}
|
|
Read -- Copy -- Update (Lesen, Kopieren, Aktualisieren)
|
|
\subsubsection{Make expert-level adjustments to RCU configuration}
|
|
CONFIG\_RCU\_EXPERT [=y] \textbf{[Y]}\\
|
|
Diese Option muss aktiviert werden, wenn Sie Anpassungen der RCU"=Konfiguration
|
|
auf Expertenebene vornehmen möchten.
|
|
Standardmäßig können solche Anpassungen nicht vorgenommen werden,
|
|
was den oft vorteilhaften Nebeneffekt hat, dass \glqq make oldconfig\grqq{} Sie
|
|
davon abhält, alle möglichen detaillierten Fragen darüber zu stellen,
|
|
wie Sie zahlreiche obskure RCU"=Optionen eingerichtet haben möchten.\\
|
|
Sagen Sie Y, wenn Sie Anpassungen an RCU auf Expertenebene vornehmen müssen.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{Force selection of TASKS\_RCU}
|
|
CONFIG\_FORCE\_TASKS\_RCU [=n] \textbf{[N]}\\
|
|
Diese Option erzwingt eine aufgabenbasierte RCU-Implementierung die nur
|
|
freiwillige Kontextwechsel verwendet (keine Preemption!), Leerlauf und
|
|
Benutzermodus-Ausführung als Ruhezustände verwendet.
|
|
Nicht für manuelle Auswahl in den meisten Fällen.
|
|
|
|
\subsubsection{Force selection of Tasks Rude RCU}
|
|
CONFIG\_FORCE\_TASKS\_RUDE\_RCU [=n] \textbf{[N]}\\
|
|
Diese Option erzwingt eine Task-basierte RCU-Implementierung, die nur
|
|
Kontextwechsel (einschließlich Preemption) und die Ausführung im
|
|
Benutzermodus als Ruhezustand verwendet. Sie erzwingt IPIs und
|
|
Kontextwechsel auf allen Online"=CPUs, auch auf den Idle"=CPUs, also
|
|
mit Vorsicht verwenden.
|
|
In den meisten Fällen nicht für die manuelle Auswahl geeignet.
|
|
|
|
\subsubsection{Force selection of Tasks Trace RCU}
|
|
CONFIG\_FORCE\_TASKS\_TRACE\_RCU [=n] \textbf{[N]}\\
|
|
Diese Option ermöglicht eine Task"=basierte RCU"=Implementierung, die
|
|
explizite rcu\_read\_lock\_trace()-Lesemarker verwendet und es ermöglicht,
|
|
dass diese Leser sowohl in der Leerlaufschleife als auch in den
|
|
CPU"=Hotplug"=Codepfaden erscheinen. Es kann IPIs auf Online-CPUs erzwingen,
|
|
auch auf Idle-CPUs, also mit Vorsicht verwenden.
|
|
In den meisten Fällen nicht für die manuelle Auswahl geeignet.
|
|
|
|
\subsubsection{Tree-based hierarchical RCU fanout value}
|
|
CONFIG\_RCU\_FANOUT [=64] \textbf{[64]}\\
|
|
Diese Option steuert den Fanout von hierarchischen Implementierungen von
|
|
RCU, so dass RCU auf Maschinen mit einer großen Anzahl von CPUs effizient
|
|
arbeiten kann. Dieser Wert muss mindestens die vierte Wurzel von NR\_CPUS
|
|
sein, wodurch NR\_CPUS wahnsinnig groß werden kann. Der Standardwert von
|
|
RCU\_FANOUT sollte für Produktionssysteme verwendet werden, aber wenn Sie
|
|
die RCU-Implementierung selbst einem Stresstest unterziehen, ermöglichen
|
|
kleine RCU\_FANOUT-Werte das Testen von Codepfaden für große Systeme auf
|
|
kleinen (kleineren) Systemen.\\
|
|
Wählen Sie eine bestimmte Zahl, wenn Sie RCU selbst testen.
|
|
Nehmen Sie den Standardwert, wenn Sie unsicher sind.\\
|
|
Symbol: RCU\_FANOUT [=64]\\
|
|
Type : integer (Ganzzahl)\\
|
|
Bereich (range) : [2 64]
|
|
|
|
\subsubsection{Tree-based hierarchical RCU leaf-level fanout value}
|
|
CONFIG\_RCU\_FANOUT\_LEAF [=16] \textbf{[16]}\\
|
|
Diese Option steuert das Fanout auf Blattebene bei hierarchischen
|
|
Implementierungen von RCU und ermöglicht es, Cache"=Misses gegen
|
|
Sperrkonflikte abzuwägen. Systeme, die ihre Scheduling"=Clock"=Interrupts
|
|
aus Gründen der Energieeffizienz synchronisieren, werden die
|
|
Standardeinstellung bevorzugen, da der kleinere Leaf-Level-Fanout die
|
|
Lock-Contention-Level akzeptabel niedrig hält. Sehr große Systeme
|
|
(Hunderte oder Tausende von CPUs) werden stattdessen diesen Wert auf den
|
|
maximal möglichen Wert setzen wollen, um die Anzahl der Cache-Misses zu
|
|
reduzieren, die während der Initialisierung der RCU-Grace"=Periode auftreten.
|
|
Diese Systeme neigen dazu, CPU-gebunden zu laufen, und werden daher nicht
|
|
von synchronisierten Interrupts unterstützt, und neigen daher dazu, sie zu
|
|
verzerren, was den Sperrkonflikt so weit reduziert, dass große Fanouts auf
|
|
Blattebene gut funktionieren. Das heißt, wenn Sie den Fanout auf Blattebene
|
|
auf eine große Zahl setzen, wird dies wahrscheinlich zu problematischen
|
|
Sperrkonflikten auf den rcu\_node"=Strukturen auf Blattebene führen, es sei
|
|
denn, Sie booten mit dem Kernelparameter skew\_tick.\\
|
|
Wählen Sie eine bestimmte Zahl, wenn Sie die RCU selbst testen.\\
|
|
Wählen Sie den maximal zulässigen Wert für große Systeme, aber bedenken Sie,
|
|
dass Sie möglicherweise auch den Kernel"=Boot"=Parameter \texttt{skew\_tick} setzen
|
|
müssen, um Konflikte bei den Sperren der rcu\_node"=Strukturen zu vermeiden.
|
|
Nehmen Sie den Standardwert, wenn Sie unsicher sind.\\
|
|
Symbol: RCU\_FANOUT\_LEAF [=64]\\
|
|
Type : integer (Ganzzahl)\\
|
|
Bereich (range) : [2 64]
|
|
|
|
\subsubsection{Enable RCU priority boosting}
|
|
CONFIG\_RCU\_BOOST [=y] \textbf{[Y]}\\
|
|
Diese Option erhöht die Priorität von preemptierten RCU-Lesern, die
|
|
die aktuelle preemptible RCU"=Schonfrist zu lange blockieren.
|
|
Diese Option verhindert auch, dass schwere Lasten den Aufruf von RCU"=Callbacks
|
|
blockieren.\\
|
|
Geben Sie hier Y an, wenn Sie mit Echtzeitanwendungen oder großen Lasten arbeiten.\\
|
|
Sagen Sie hier N ein, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Milliseconds to delay boosting after RCU grace-period start}$~$\\
|
|
CONFIG\_RCU\_BOOST\_DELAY [=500] \textbf{[500]}\\
|
|
Diese Option gibt die Zeit an, die nach dem Beginn einer bestimmten Karenzzeit
|
|
gewartet werden soll, bevor die Priorität von RCU-Lesern, die diese Karenzzeit
|
|
blockieren, erhöht wird.\\
|
|
Beachten Sie, dass jeder RCU-Leser, der eine beschleunigte RCU-Schonfrist
|
|
blockiert, sofort hochgestuft wird.\\
|
|
Akzeptieren Sie die Standardeinstellung, wenn Sie unsicher sind.\\
|
|
Symbol: RCU\_BOOST\_DELAY [=500]\\
|
|
Typ : Integer (Ganzzahl)\\
|
|
Bereich : [0 3000]
|
|
|
|
\paragraph{Perform RCU expedited work in a real-time kthread}$~$\\
|
|
CONFIG\_RCU\_EXP\_KTHREAD [=n] \textbf{[N]}\\
|
|
Verwenden Sie diese Option, um die Latenzzeiten der beschleunigten Neuheitsschonfristen
|
|
weiter zu reduzieren, was allerdings mit mehr Störungen verbunden ist.
|
|
Diese Option ist standardmäßig auf PREEMPT\_RT=y-Kerneln deaktiviert,
|
|
die beschleunigte Neuheitsschonfristen nach dem Booten durch die bedingungslose
|
|
Einstellung rcupdate.rcu\_normal\_after\_boot=1 deaktivieren.\\
|
|
Akzeptieren Sie die Voreinstellung, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{Offload RCU callback processing from boot-selected CPUs}
|
|
CONFIG\_RCU\_NOCB\_CPU [=y] \textbf{[Y]}\\
|
|
Verwenden Sie diese Option, um den Jitter des Betriebssystems für aggressive HPC- oder
|
|
Echtzeit-Workloads zu reduzieren.
|
|
Sie kann auch verwendet werden, um RCU-Callback-Aufrufe auf energieeffiziente CPUs in
|
|
batteriebetriebenen asymmetrischen Multiprozessoren auszulagern. Der Preis für diesen
|
|
reduzierten Jitter ist, dass der Overhead von call\_rcu() ansteigt und dass bei einigen
|
|
Workloads ein erheblicher Anstieg der Kontextwechselraten zu verzeichnen ist.\\
|
|
Diese Option entlastet den Aufruf von Callbacks von der Gruppe von CPUs, die zur
|
|
Boot-Zeit durch den rcu\_nocbs-Parameter angegeben wird. Für jede dieser CPUs wird ein
|
|
kthread (\glqq rcuox/N\grqq{}) erstellt, um Callbacks aufzurufen, wobei \glqq N\grqq{} die CPU ist, die
|
|
entlastet wird, und wobei \glqq x\grqq{} \glqq p\grqq{} für RCU-preempt
|
|
(PREEMPTION-Kernel) und \glqq s\grqq{} für
|
|
RCU-sched (!PREEMPTION-Kernel) ist. Nichts hindert diesen kthread daran, auf den
|
|
angegebenen CPUs zu laufen, aber (1) die kthreads können zwischen jedem Callback
|
|
preempted werden, und (2) Affinität oder cgroups können verwendet werden, um die
|
|
kthreads zu zwingen, auf jeder gewünschten Gruppe von CPUs zu laufen.\\
|
|
Sagen Sie hier Y, wenn Sie trotz des zusätzlichen Overheads ein geringeres
|
|
OS-Jitter benötigen.\\
|
|
Sagen Sie hier N, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Offload RCU callback processing from all CPUs by default}$~$\\
|
|
CONFIG\_RCU\_NOCB\_CPU\_DEFAULT\_ALL [=n] \textbf{[N]}\\
|
|
Verwenden Sie diese Option, um die Callback-Verarbeitung standardmäßig von allen
|
|
CPUs zu entlasten, wenn der Boot-Parameter rcu\_nocbs oder nohz\_full nicht vorhanden
|
|
ist. Dadurch wird auch die Notwendigkeit vermieden, Boot-Parameter zu verwenden, um
|
|
den Effekt der Entlastung aller CPUs beim Booten zu erreichen.\\
|
|
Geben Sie hier Y an, wenn Sie alle CPUs standardmäßig beim Booten entlasten wollen.\\
|
|
Sagen Sie hier N, wenn Sie sich nicht sicher sind.
|
|
|
|
\paragraph{Offload RCU callback from real-time kthread}$~$\\
|
|
CONFIG\_RCU\_NOCB\_CPU\_CB\_BOOST [=n] \textbf{[N]}\\
|
|
Verwenden Sie diese Option, um ausgelagerte Rückrufe als SCHED\_FIFO aufzurufen, um
|
|
ein Aushungern durch schwere SCHED\_OTHER-Hintergrundlast zu vermeiden. Natürlich
|
|
führt die Ausführung als SCHED\_FIFO während Callback Floods dazu, dass die rcuo[ps]
|
|
kthreads die CPU für Hunderte von Millisekunden oder mehr monopolisieren.
|
|
Wenn Sie diese Option aktivieren, müssen Sie daher sicherstellen, dass
|
|
latenzempfindliche Aufgaben entweder mit höherer Priorität oder auf einer anderen CPU
|
|
ausgeführt werden.\\
|
|
Geben Sie hier Y an, wenn Sie die RT-Priorität für die Auslagerung von kthreads
|
|
festlegen möchten.\\
|
|
Sagen Sie hier N, wenn Sie einen !PREEMPT\_RT-Kernel bauen und sich unsicher sind.
|
|
|
|
\subsubsection{Tasks Trace RCU readers use memory barriers in user and idle}
|
|
CONFIG\_TASKS\_TRACE\_RCU\_READ\_MB [=n] \textbf{[N]}\\
|
|
Verwenden Sie diese Option, um die Anzahl der IPIs (inter-processor interrupts),
|
|
die an CPUs gesendet werden,
|
|
die im Benutzerraum ausgeführt werden oder sich im Leerlauf befinden, während Tasks
|
|
RCU-Tilgungsfristen verfolgen, weiter zu reduzieren.
|
|
Da eine vernünftige Einstellung des Kernel-Boot-Parameters
|
|
rcupdate.rcu\_task\_ipi\_delay solche IPIs für viele Arbeitslasten eliminiert, ist
|
|
die richtige Einstellung dieser Kconfig-Option vor allem für aggressive
|
|
Echtzeitinstallationen und für batteriebetriebene Geräte wichtig, daher die oben
|
|
gewählte Standardeinstellung.\\
|
|
Sagen Sie hier Y, wenn Sie IPIs hassen.\\
|
|
Sagen Sie hier N, wenn Sie leseseitige Speicherbarrieren hassen.\\
|
|
Nehmen Sie die Standardeinstellung, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{RCU callback lazy invocation functionality}
|
|
CONFIG\_RCU\_LAZY [=y] \textbf{[Y]}\\
|
|
Um Strom zu sparen, sollten Sie RCU-Rückrufe stapeln und nach einer Verzögerung,
|
|
einem Speicherdruck oder einer zu großen Rückrufliste flushen.
|
|
|
|
\subsubsection{RCU callback-batch backup time check}
|
|
CONFIG\_RCU\_DOUBLE\_CHECK\_CB\_TIME [=y] \textbf{[Y]}\\
|
|
Verwenden Sie diese Option, um eine präzisere Durchsetzung des Modulparameters
|
|
rcutree.rcu\_resched\_ns in Situationen zu ermöglichen, in denen ein einziger
|
|
RCU-Callback Hunderte von Mikrosekunden lang laufen könnte, wodurch die
|
|
32-Callback-Batching-Funktion, die verwendet wird, um die Kosten der feinkörnigen,
|
|
aber teuren local\_clock()-Funktion zu amortisieren, unterlaufen wird.\\
|
|
Diese Option rundet rcutree.rcu\_resched\_ns auf den nächsten Jiffy auf und setzt
|
|
die 32-Callback-Batching-Funktion außer Kraft, wenn diese Grenze überschritten wird.\\
|
|
Sagen Sie hier Y, wenn Sie eine strengere Durchsetzung des Rückruflimits benötigen.\\
|
|
Sagen Sie hier N, wenn Sie unsicher sind.
|
|
|
|
\subsection{Kernel .config support}
|
|
CONFIG\_IKCONFIG [=y] \textbf{[Y]}\\
|
|
Mit dieser Option kann der gesamte Inhalt der \glqq .config\grqq{}-Datei des Linux-Kernels im
|
|
Kernel gespeichert werden. Sie dokumentiert, welche Kernel-Optionen in einem
|
|
laufenden Kernel oder in einem On-Disk-Kernel verwendet werden.
|
|
Diese Informationen können mit dem Skript scripts/extract-ikconfig aus der
|
|
Kernel-Image-Datei extrahiert und als Eingabe verwendet werden, um den aktuellen
|
|
Kernel neu zu erstellen oder einen anderen Kernel zu bauen.
|
|
Sie können auch aus einem laufenden Kernel extrahiert werden, indem
|
|
/proc/config.gz gelesen wird, falls dies aktiviert ist (siehe unten).\\
|
|
Definiert mit init/Kconfig:686
|
|
|
|
\subsubsection{Enable access to .config through /proc/config.gz}
|
|
CONFIG\_IKCONFIG\_PROC [=y] \textbf{[Y]}\\
|
|
Diese Option ermöglicht den Zugriff auf die Kernelkonfigurationsdatei über
|
|
/proc/config.gz.
|
|
|
|
\subsection{Enable kernel headers through /sys/kernel/kheaders.tar.xz}
|
|
CONFIG\_IKHEADERS [=m] \textbf{[M]}\\*
|
|
Diese Option ermöglicht den Zugriff auf die In-Kernel-Header, die während des
|
|
Build-Prozesses erzeugt werden. Diese können verwendet werden, um
|
|
eBPF-Tracing-Programme oder ähnliche Programme zu erstellen. Wenn Sie die Header
|
|
als Modul erstellen, wird ein Modul namens \texttt{kheaders.ko} erstellt, das bei Bedarf
|
|
geladen werden kann, um Zugriff auf die Header zu erhalten.
|
|
|
|
\subsection{Kernel log buffer size (16 \texorpdfstring{$\Rightarrow$}{=>} 64KB, 17 \texorpdfstring{$\Rightarrow$}{=>} 128KB)}
|
|
CONFIG\_LOG\_BUF\_SHIFT [=17] \textbf{[17]}\\*
|
|
Wählen Sie die minimale Größe des Kernel-Protokollpuffers als eine Potenz von 2 aus.
|
|
Die endgültige Größe wird durch den Konfigurationsparameter LOG\_CPU\_MAX\_BUF\_SHIFT
|
|
beeinflusst, siehe unten. Eine höhere Größe kann auch durch den Boot-Parameter
|
|
\glqq log\_buf\_len\grqq{} erzwungen werden.\\
|
|
Beispiele:\\
|
|
\indent 17 $\Rightarrow$ 128 KB\\
|
|
\indent 16 $\Rightarrow$ 64 KB\\
|
|
\indent 15 $\Rightarrow$ 32 KB\\
|
|
\indent 14 $\Rightarrow$ 16 KB\\
|
|
\indent 13 $\Rightarrow$ 8 KB\\
|
|
\indent 12 $\Rightarrow$ 4 KB\\
|
|
Symbol: LOG\_BUF\_SHIFT\\
|
|
Type: Integer (Ganzzahl)\\
|
|
Bereich (range): [12 25]
|
|
\subsection{CPU kernel log buffer size contribution (13 \texorpdfstring{$\Rightarrow$}{=>} 8 KB, 17 \texorpdfstring{$\Rightarrow$}{=>} 128KB)}
|
|
CONFIG\_LOG\_BUF\_SHIFT [=12] \textbf{[12]}\\
|
|
Diese Option ermöglicht es, die Standardgröße des Ringpuffers entsprechend der Anzahl
|
|
der CPUs zu erhöhen. Der Wert definiert den Beitrag jeder CPU als eine Potenz von 2.
|
|
Der beanspruchte Speicherplatz beträgt in der Regel nur wenige Zeilen, kann aber viel
|
|
mehr sein, wenn Probleme gemeldet werden, z.\,B. bei Rückverfolgungen.
|
|
Die erhöhte Größe bedeutet, dass ein neuer Puffer zugewiesen werden muss und der
|
|
ursprüngliche statische Puffer ungenutzt ist. Dies ist nur auf Systemen mit mehr CPUs
|
|
sinnvoll. Daher wird dieser Wert nur verwendet, wenn die Summe der Beiträge größer ist
|
|
als die Hälfte des Standard-Kernel-Ringpuffers, wie durch \texttt{LOG\_BUF\_SHIFT} definiert.
|
|
Die Standardwerte sind so eingestellt, dass mehr als 16 CPUs erforderlich sind, um die
|
|
Zuweisung auszulösen. Diese Option wird auch ignoriert, wenn der Kernelparameter
|
|
\glqq log\_buf\_len\grqq{} verwendet wird, da er eine exakte (Zweierpotenz) Größe des
|
|
Ringpuffers erzwingt. Die Anzahl der möglichen CPUs wird für diese Berechnung verwendet,
|
|
wobei Hotplugging ignoriert wird, so dass die Berechnung für das Worst-Case-Szenario
|
|
optimal ist und gleichzeitig ein einfacher Algorithmus ab dem Hochfahren verwendet
|
|
werden kann. Beispiele für Verschiebungswerte und ihre Bedeutung:\\
|
|
\indent 17 $\Rightarrow$ 128 KB für jede CPU\\
|
|
\indent 16 $\Rightarrow$ 64 KB für jede CPU\\
|
|
\indent 15 $\Rightarrow$ 32 KB für jede CPU\\
|
|
\indent 14 $\Rightarrow$ 16 KB für jede CPU\\
|
|
\indent 13 $\Rightarrow$ 8 KB für jede CPU\\
|
|
\indent 12 $\Rightarrow$ 4 KB für jede CPU\\
|
|
Symbol: LOG\_CPU\_MAX\_BUF\_SHIFT\\
|
|
Type: Integer (Ganzzahl)\\
|
|
Bereich (range): [0 21]
|
|
|
|
\subsection{Printk indexing debugfs interface)}
|
|
CONFIG\_PRINTK\_INDEX [=y] \textbf{[Y]}\\
|
|
Unterstützung für die Indizierung aller zur Kompilierzeit bekannten
|
|
printk-Formate unter\\
|
|
$<$debugfs$>$/printk/index/$<$module$>$ hinzufügen.
|
|
Dies kann als Teil der Wartung von Daemonen, die /dev/kmsg überwachen,
|
|
verwendet werden, da es die Überprüfung der in einem Kernel vorhandenen
|
|
printk-Formate erlaubt, was die Erkennung von Fällen ermöglicht,
|
|
in denen überwachte printks geändert oder nicht mehr vorhanden sind.\\
|
|
Es gibt keine zusätzlichen Laufzeitkosten für printk, wenn dies aktiviert ist.
|
|
|
|
\subsection{Scheduler features \texorpdfstring{$\rightarrow$}{->}}
|
|
\textit{(Scheduler-Funktionen)}
|
|
|
|
\subsubsection{Enable utilization clamping for RT/FAIR tasks}
|
|
CONFIG\_UCLAMP\_TASK [=y] \textbf{[Y]}\\
|
|
Diese Funktion ermöglicht es dem Scheduler, die geklemmte Auslastung jeder CPU
|
|
auf der Grundlage der auf dieser CPU geplanten RUNNABLE-Tasks zu verfolgen.
|
|
Mit dieser Option kann der Benutzer die minimale und maximale CPU-Auslastung
|
|
angeben, die für RUNNABLE-Aufgaben zulässig ist. Die maximale Auslastung
|
|
definiert die maximale Häufigkeit, mit der ein Task laufen soll, während die
|
|
minimale Auslastung die minimale Häufigkeit definiert, mit der er laufen soll.\\
|
|
Sowohl die Minimal- als auch die Maximalwerte für die Auslastung sind Hinweise
|
|
für den Scheduler, um seine Frequenzauswahl zu verbessern, aber sie erzwingen
|
|
oder gewähren keine bestimmte Bandbreite für Tasks.\\
|
|
Im Zweifelsfall sagen Sie N für Nein.
|
|
|
|
\paragraph{Number of supported utilization clamp buckets}$~$\\
|
|
CONFIG\_UCLAMP\_BUCKETS\_COUNT [=5] \textbf{[5]}\\
|
|
Legt die Anzahl der zu verwendenden Klammerbereiche fest. Der Bereich der
|
|
einzelnen Buckets ist SCHED\_CAPACITY\_SCALE/UCLAMP\_BUCKETS\_COUNT.
|
|
Je höher die Anzahl der Clamp-Buckets, desto feiner die Granularität und
|
|
desto höher die Präzision der Clamp-Aggregation und -Verfolgung während der
|
|
Laufzeit.
|
|
Mit dem minimalen Konfigurationswert haben wir beispielsweise 5~Clamp"=Buckets,
|
|
die jeweils $\qty{20}{\percent}$ Auslastung verfolgen. Eine um $\qty{25}{\percent}$ gesteigerte Aufgabe
|
|
wird im Bucket [20..39]\% gezählt und setzt den effektiven Wert der
|
|
Bucketklemme auf $\qty{25}{\percent}$.
|
|
Wenn eine zweite, um $\qty{30}{\percent}$ erhöhte Aufgabe auf derselben CPU eingeplant wird,
|
|
wird diese Aufgabe im selben Bucket wie die erste Aufgabe gezählt und erhöht
|
|
den effektiven Bucket"=Clamp"=Wert auf $\qty{30}{\percent}$.
|
|
Der effektive Klemmwert eines Bereichs wird auf seinen Nennwert ($\qty{20}{\percent}$ im
|
|
obigen Beispiel) zurückgesetzt, wenn keine weiteren Aufgaben mehr in diesem
|
|
Bereich gezählt werden. Bei einigen Aufgaben kann eine zusätzliche
|
|
Verstärkungs-/Kappungsmarge hinzugefügt werden. Im obigen Beispiel wird
|
|
die $\qty{25}{\percent}$-Aufgabe auf $\qty{30}{\percent}$ angehoben,
|
|
bis sie die CPU verlässt.
|
|
Sollte dies auf bestimmten Systemen nicht akzeptabel sein, ist es immer
|
|
möglich, den Spielraum zu verringern, indem die Anzahl der Clamp"=Buckets
|
|
erhöht wird, um den verbrauchten Speicher gegen die Genauigkeit der
|
|
Laufzeitverfolgung einzutauschen.\\
|
|
Im Zweifelsfall sollten Sie den Standardwert verwenden.
|
|
|
|
\subsection{Memory placement aware NUMA scheduler}
|
|
CONFIG\_NUMA\_BALANCING [=y] \textbf{[Y]}\\
|
|
Diese Option bietet Unterstützung für die automatische
|
|
NUMA-kompatible Speicher-/Task-Platzierung.
|
|
Der Mechanismus ist recht primitiv und basiert darauf, dass Speicher
|
|
migriert wird, wenn er Referenzen auf den Knoten hat, auf dem die Aufgabe läuft.
|
|
Dieses System ist auf UMA"=Systemen inaktiv.
|
|
|
|
\subsubsection{Automatically enable NUMA aware memory/task placemnent}
|
|
CONFIG\_NUMA\_BALANCING\_DEFAULT\_ENABLED [=y] \textbf{[Y]}\\
|
|
Wenn diese Option gesetzt ist, wird der automatische NUMA"=Ausgleich aktiviert,
|
|
wenn das System auf einem NUMA"=Rechner läuft.
|
|
|
|
\subsection{Control Group support \texorpdfstring{$\rightarrow$}{->}}
|
|
CONFIG\_CGROUPS [=y] \textbf{[Y]}\\
|
|
(Unterstützung der Kontrollgruppe)\\
|
|
Diese Option bietet Unterstützung für die Gruppierung von Prozessgruppen zur
|
|
Verwendung mit Prozesskontrollsubsystemen wie Cpusets, CFS, Speicherkontrolle
|
|
oder Geräteisolierung.
|
|
\\Siehe
|
|
\begin{itemize}
|
|
\item Dokumentation/scheduler/sched-design-CFS.rst (CFS)
|
|
\item Documentation/admin-guide/cgroup-v1/ (Funktionen für Gruppierung,
|
|
Isolierung und Ressourcenkontrolle)
|
|
\end{itemize}
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{Favor dynamic modification latency reduction by default}
|
|
CONFIG\_CGROUP\_FAVOR\_DYNMODS [=n] \textbf{[N]}\\
|
|
Diese Option aktiviert standardmäßig die Einhängeoption
|
|
\glqq favordynmods\grqq{}, die die Latenzzeiten dynamischer C-Gruppen"=Änderungen
|
|
wie Task-Migrationen und Controller-Ein-/Ausschaltungen
|
|
auf Kosten von Hot-Path-Operationen wie Forks und Exits
|
|
verteuert.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{Memory controller}
|
|
CONFIG\_MEMCG [=y] \textbf{[Y]}\\
|
|
Ermöglicht die Kontrolle über den Speicherbedarf von Tasks in einer cgroup.
|
|
|
|
\subsubsection{IO controller}
|
|
CONFIG\_BLK\_CGROUP [=y] \textbf{[Y]}\\
|
|
Generische Block IO Controller cgroup Schnittstelle. Dies ist die gemeinsame
|
|
cgroup-Schnittstelle, die von verschiedenen IO-Kontrollstrategien verwendet
|
|
werden sollte.\\
|
|
Derzeit wird sie vom CFQ IO Scheduler zur Erkennung von Task-Gruppen und zur
|
|
Steuerung der Zuweisung von Festplattenbandbreite (proportionale
|
|
Zeitscheibenzuweisung) an solche Task-Gruppen verwendet. Sie wird auch von
|
|
der Bio-Throttling-Logik in der Blockschicht verwendet, um eine Obergrenze
|
|
für die IO-Raten auf einem Gerät einzuführen.\\
|
|
Diese Option aktiviert nur die generische Infrastruktur des Block-IO-Controllers.
|
|
Man muss auch die tatsächliche IO-Kontrolllogik/-Politik aktivieren.
|
|
Um die proportionale Aufteilung der Festplattenbandbreite in CFQ zu aktivieren,
|
|
setzen Sie
|
|
CONFIG\_BFQ\_GROUP\_IOSCHED=y; für die Aktivierung der Drosselungspolitik
|
|
setzen Sie CONFIG\_BLK\_DEV\_THROTTLING=y.\\
|
|
Weitere Informationen finden Sie unter
|
|
Documentation/admin-guide/cgroup-v1/blkio-controller.rst.
|
|
|
|
\subsubsection{CPU controller \texorpdfstring{$\rightarrow$}{->}}
|
|
CONFIG\_CGROUP\_SCHED [=y] \textbf{[Y]}\\
|
|
Diese Funktion ermöglicht es dem CPU-Scheduler, Task"=Gruppen zu erkennen und
|
|
die Zuweisung von CPU"=Bandbreite an solche Task"=Gruppen zu steuern.
|
|
Er verwendet cgroups, um Tasks zu gruppieren.
|
|
|
|
\paragraph{Group scheduling for SCHED\_OTHER}$~$\\
|
|
CONFIG\_FAIR\_GROUP\_SCHED [=y] \textbf{[Y]}\\
|
|
\textit{Für diese Option gibt es keine Hilfe.}
|
|
|
|
\subparagraph{CPU bandwidth provisioning for FAIR\_GROUP\_SCHED}$~$\\
|
|
CONFIG\_CFS\_BANDWIDTH [=y] \textbf{[Y]}\\
|
|
Mit dieser Option können Benutzer CPU-Bandbreitenraten (Limits) für Aufgaben
|
|
festlegen, die innerhalb des Fair Group Schedulers laufen.
|
|
Gruppen, für die kein Limit festgelegt wurde, gelten als uneingeschränkt
|
|
und werden ohne Einschränkung ausgeführt.\\
|
|
Weitere Informationen finden Sie unter Documentation/scheduler/sched-bwc.rst.
|
|
|
|
\paragraph{Group scheduling for SCHED\_RR/FIFO}$~$\\
|
|
CONFIG\_RT\_GROUP\_SCHED [=n] \textbf{[N]}\\
|
|
Mit dieser Funktion können Sie den Task-Gruppen explizit echte CPU-Bandbreite
|
|
zuweisen. Wenn sie aktiviert ist, wird es auch unmöglich, Echtzeitaufgaben
|
|
für Nicht"=Root"=Benutzer zu planen, bis Sie ihnen Echtzeitbandbreite zuweisen.\\
|
|
Weitere Informationen finden Sie unter Documentation/scheduler/sched-rt-group.rst.
|
|
|
|
\subsubsection{Utilization clamping per group of tasks}
|
|
CONFIG\_UCLAMP\_TASK\_GROUP [=y] \textbf{[Y]}\\
|
|
Mit dieser Funktion kann der Scheduler die geklemmte Auslastung jeder CPU auf der
|
|
Grundlage der RUNNABLE"=Tasks, die derzeit auf dieser CPU geplant sind, verfolgen.
|
|
Wenn diese Option aktiviert ist, kann der Benutzer eine minimale und maximale
|
|
CPU-Bandbreite angeben, die für jede einzelne Aufgabe in einer Gruppe zulässig ist.
|
|
Mit der maximalen Bandbreite kann die maximale Frequenz, die ein Task verwenden kann,
|
|
festgelegt werden, während mit der minimalen Bandbreite eine minimale Frequenz
|
|
festgelegt werden kann, die ein Task immer verwenden wird.
|
|
Bei aktivierter aufgabengruppenbasierter Auslastungsbegrenzung wird ein eventuell
|
|
angegebener aufgabenspezifischer Begrenzungswert durch den von cgroup angegebenen
|
|
Begrenzungswert eingeschränkt. Sowohl die minimale als auch die maximale Task"=Klemmung
|
|
kann nicht größer sein als die entsprechende auf Task"=Gruppen"=Ebene definierte Klemmung.\\
|
|
Im Zweifelsfall sagen Sie N.
|
|
|
|
\subsubsection{PIDs controller}
|
|
CONFIG\_CGROUP\_PIDS [=y] \textbf{[Y]}\\
|
|
Erzwingt die Begrenzung der Prozessanzahl im Bereich einer cgroup. Jeder Versuch, mehr
|
|
Prozesse zu forken, als in der cgroup erlaubt sind, schlägt fehl.
|
|
PIDs sind grundsätzlich eine globale Ressource, da es ziemlich trivial ist, eine
|
|
PID-Erschöpfung zu erreichen, bevor man auch nur eine konservative kmemcg-Grenze erreicht.
|
|
Infolgedessen ist es möglich, ein System zum Stillstand zu bringen, ohne durch andere
|
|
cgroup-Richtlinien eingeschränkt zu werden. Der PID"=Regler ist dafür ausgelegt, dies zu verhindern.
|
|
Es sollte beachtet werden, dass organisatorische Operationen (wie z.\,B. das Anhängen an
|
|
eine cgroup-Hierarchie) *nicht* durch den PIDs-Controller blockiert werden, da das PIDs-Limit
|
|
nur die Fähigkeit eines Prozesses zum Forking, nicht aber zum Anhängen an eine cgroup beeinflusst.
|
|
|
|
\subsubsection{RDMA controller}
|
|
CONFIG\_CGROUP\_RDMA [=y] \textbf{[Y]}\\
|
|
Ermöglicht die Durchsetzung der vom IB-Stack definierten RDMA-Ressourcen. Es ist relativ
|
|
einfach für Verbraucher, RDMA-Ressourcen zu erschöpfen, was dazu führen kann, dass Ressourcen
|
|
für andere Verbraucher nicht mehr verfügbar sind. Der RDMA-Controller ist dafür ausgelegt,
|
|
dies zu verhindern. Das Anhängen von Prozessen mit aktiven RDMA-Ressourcen an die
|
|
cgroup-Hierarchie ist erlaubt, auch wenn die Grenze der Hierarchie überschritten werden kann.
|
|
|
|
\subsubsection{Freezer controller}
|
|
CONFIG\_CGROUP\_FREEZER [=y] \textbf{[Y]}\\
|
|
Ermöglicht das Einfrieren und Aufheben des Einfrierens aller Aufgaben in einer C-Group.
|
|
Diese Option betrifft die ORIGINAL cgroup-Schnittstelle. Der cgroup2-Speicher-Controller
|
|
enthält standardmäßig wichtige In-Kernel-Speicherverbraucher.\\
|
|
Wenn Sie cgroup2 verwenden, sagen Sie N.
|
|
|
|
\subsubsection{HugeTLB controller}
|
|
CONFIG\_CGROUP\_HUGETLB [=y] \textbf{[Y]}\\
|
|
Bietet eine cgroup-Steuerung für HugeTLB"=Seiten. Wenn Sie dies aktivieren, können Sie die
|
|
HugeTLB"=Nutzung pro cgroup begrenzen. Die Begrenzung wird während eines Seitenfehlers
|
|
durchgesetzt. Da \mbox{HugeTLB} keine Seitenrückforderung unterstützt, bedeutet die Durchsetzung
|
|
des Limits zum Zeitpunkt des Seitenfehlers, dass die Anwendung ein SIGBUS-Signal erhält,
|
|
wenn sie versucht, über das Limit hinaus auf HugeTLB-Seiten zuzugreifen. Dies setzt voraus,
|
|
dass die Anwendung im Voraus weiß, wie viele HugeTLB-Seiten sie für ihre Nutzung benötigt.
|
|
Die Kontrollgruppe wird im dritten Page-lru-Zeiger verfolgt. Dies bedeutet, dass wir die
|
|
Steuergruppe nicht mit einer riesigen Seite von weniger als 3~Seiten verwenden können.
|
|
|
|
\subsubsection{Cpuset controller}
|
|
CONFIG\_CPUSETS [=y] \textbf{[Y]}\\
|
|
Mit dieser Option können Sie CPUSETs erstellen und verwalten, die es ermöglichen, ein System
|
|
dynamisch in Gruppen von CPUs und Speicherknoten zu partitionieren und Aufgaben zuzuweisen,
|
|
die nur innerhalb dieser Gruppen ausgeführt werden.
|
|
Dies ist vor allem auf großen SMP- oder NUMA"=Systemen nützlich.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Include legacy /proc/$<$pid$>$/cpuset file}$~$\\
|
|
CONFIG\_PROC\_PID\_CPUSET [=y] \textbf{[Y]}\\
|
|
This option will let you create and manage CPUSETs which allow dynamically partitioning a
|
|
system into sets of CPUs and Memory Nodes and assigning tasks to run only within those sets.
|
|
This is primarily useful on large SMP or NUMA systems.\\
|
|
Say N if unsure.
|
|
|
|
\subsubsection{Device controller}
|
|
CONFIG\_CGROUP\_DEVICE [=y] \textbf{[Y]}\\
|
|
Bietet einen cgroup-Controller an, der Whitelists für Geräte implementiert,
|
|
die ein Prozess in der cgroup mknod oder öffnen kann.
|
|
|
|
\subsubsection{Simple CPU accounting controller}
|
|
CONFIG\_CGROUP\_CPUACCT [=y] \textbf{[Y]}\\*
|
|
(Einfacher CPU-Accounting-Controller)\\
|
|
Bietet einen einfachen Controller für die Überwachung des gesamten
|
|
CPU"=Verbrauchs der Tasks in einer cgroup an.
|
|
|
|
\subsubsection{Perf controller}
|
|
CONFIG\_CGROUP\_PERF [=y] \textbf{[Y]}\\
|
|
Diese Option erweitert den Modus perf per-cpu, um die Überwachung auf Threads zu beschränken,
|
|
die zu der angegebenen cgroup gehören und auf der angegebenen CPU laufen.
|
|
Sie kann auch verwendet werden, um die cgroup ID in Stichproben zu haben,
|
|
so dass sie Leistungsereignisse zwischen cgroups überwachen kann.\\
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsubsection{Support for eBPF programs attached to cgroups}
|
|
CONFIG\_CGROUP\_BPF [=y] \textbf{[Y]}\\
|
|
Erlaubt das Anhängen von eBPF-Programmen an eine cgroup mit dem
|
|
bpf(2)-Syscall-Befehl\\
|
|
\texttt{BPF\_PROG\_ATTACH}.\\
|
|
In welchem Kontext auf diese Programme zugegriffen wird, hängt von der Art des Attachments ab.
|
|
Zum Beispiel werden Programme, die mit BPF\_CGROUP\_INET\_INGRESS angehängt werden,
|
|
auf dem Ingress"=Pfad von inet"=Sockets ausgeführt.
|
|
|
|
\subsubsection{Misc resource controller}
|
|
CONFIG\_CGROUP\_MISC [=y] \textbf{[Y]}\\
|
|
Bietet einen Controller für verschiedene Ressourcen auf einem Host.
|
|
Verschiedene skalare Ressourcen sind die Ressourcen auf dem Host-System, die nicht wie die
|
|
anderen cgroups abstrahiert werden können. Dieser Controller verfolgt und begrenzt die
|
|
verschiedenen Ressourcen, die von einem Prozess verwendet werden, der an eine
|
|
cgroup"=Hierarchie angeschlossen ist.
|
|
Weitere Informationen finden Sie im Abschnitt misc cgroup in /Documentation/admin-guide/cgroup-v2.rst.
|
|
|
|
\subsubsection{Debug controller}
|
|
CONFIG\_CGROUP\_DEBUG [=n] \textbf{[N]}\\
|
|
Diese Option aktiviert einen einfachen Controller, der Debugging"=Informationen über das
|
|
cgroups"=Frame\-work exportiert. Dieser Controller ist nur für das Debugging von Kontroll-C"=Gruppen gedacht.
|
|
Seine Schnitt\-stellen sind nicht stabil.\\
|
|
Sagen Sie N.
|
|
|
|
\subsection{Namespaces support \texorpdfstring{$\rightarrow$}{->}}
|
|
CONFIG\_NAMESPACES [=y] \textbf{[Y]}\\
|
|
(Unterstützung von Namensräumen, namespaces)\\
|
|
Bietet die Möglichkeit, Aufgaben mit verschiedenen Objekten unter Verwendung derselben Kennung
|
|
arbeiten zu lassen. Zum Beispiel kann sich dieselbe IPC-ID auf verschiedene Objekte beziehen oder
|
|
dieselbe Benutzer-ID oder pid kann sich auf verschiedene Aufgaben beziehen, wenn sie in verschiedenen
|
|
Namensräumen verwendet werden.
|
|
|
|
\subsubsection{UTS namespace}
|
|
CONFIG\_UTS\_NS [=y] \textbf{[Y]}\\
|
|
In diesem Namensraum sehen Aufgaben verschiedene Informationen, die mit dem Systemaufruf
|
|
\texttt{uname()} bereitgestellt werden.
|
|
|
|
\subsubsection{TIME namespace}
|
|
CONFIG\_TIME\_NS [=y] \textbf{[Y]}\\
|
|
In diesem Namespace können boottime und monotone Uhren eingestellt werden.
|
|
Die Zeit läuft dann mit der gleichen Geschwindigkeit weiter.
|
|
|
|
\subsubsection{IPC namespace}
|
|
CONFIG\_IPC\_NS [=y] \textbf{[Y]}\\
|
|
In diesem Namensraum arbeiten Aufgaben mit IPC-IDs (Interprozess-IDs), die jeweils
|
|
verschiedenen IPC-Objekten in verschiedenen Namensräumen entsprechen.
|
|
|
|
\subsubsection{User namespace}
|
|
CONFIG\_USER\_NS [=y] \textbf{[Y]}\\
|
|
Dies ermöglicht es Containern, d.\,h. V"=Servern, Benutzernamensräume zu verwenden,
|
|
um verschiedene Benutzerinformationen für verschiedene Server bereitzustellen.
|
|
Wenn Benutzernamensräume im Kernel aktiviert sind, wird empfohlen, dass die Option \texttt{MEMCG} ebenfalls
|
|
aktiviert wird und dass der Benutzerbereich die Speicherkontrollgruppen verwendet,
|
|
um die Speichermenge zu begrenzen, die nicht privilegierte Benutzer verwenden können.
|
|
|
|
\paragraph{Allow unprivileged users to create namespaces}$~$\\
|
|
CONFIG\_USERS\_NS\_UNPRIVILEGED [=y] \textbf{[Y]}\\
|
|
Wenn diese Funktion deaktiviert ist, können unprivilegierte Benutzer keine neuen Namensräume
|
|
erstellen. Die Möglichkeit, dass Benutzer ihre eigenen Namespaces erstellen können, war Teil mehrerer
|
|
kürzlich erfolgter lokaler Privilegienerweiterungen. Wenn Sie also Benutzernamespaces benötigen,
|
|
aber paranoid bzw. sicherheitsbewusst sind, sollten Sie diese Funktion deaktivieren.
|
|
Diese Einstellung kann zur Laufzeit mit dem
|
|
\texttt{kernel.unprivileged\_userns\_clone sysctl}
|
|
außer Kraft gesetzt werden.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{PID namespace}
|
|
CONFIG\_PID\_NS [=y] \textbf{[Y]}\\
|
|
Unterstützung von Prozess-ID-Namensräumen. Dies ermöglicht es, mehrere Prozesse mit der gleichen pid
|
|
zu haben, solange sie sich in verschiedenen pid-Namensräumen befinden. Dies ist ein Baustein von Containern.
|
|
|
|
\subsubsection{Network namespace}
|
|
CONFIG\_NET\_NS [=y] \textbf{[Y]}\\
|
|
Ermöglicht es dem Benutzer, scheinbar mehrere Instanzen des Netzwerkstapels zu erstellen.
|
|
|
|
\subsection{Checkpoint/restore support}
|
|
CONFIG\_CHECKPOINT\_RESTORE [=y] \textbf{[Y]}\\
|
|
Ermöglicht zusätzliche Kernel-Funktionen in einer Art Checkpoint/Restore.
|
|
Insbesondere fügt es zu\-sätz\-liche prctl"=Codes zum Einrichten von Prozesstext, Daten- und Heap"=Segmentgrößen
|
|
sowie einige zusätzliche \texttt{/proc}-Dateisystemeinträge hinzu.\\
|
|
Wenn Sie unsicher sind, geben Sie hier N an.
|
|
|
|
|
|
\subsection{Automatic process group scheduling}
|
|
CONFIG\_SCHED\_AUTOGROUP [=y] \textbf{[Y]}\\
|
|
Mit dieser Option wird der Scheduler für gängige Desktop"=Workloads optimiert,
|
|
indem automatisch Aufgabengruppen erstellt und aufgefüllt werden.
|
|
Diese Trennung von Arbeitslasten isoliert aggressive CPU"=Brenner (wie Build"=Jobs) von Desktop"=Anwendungen.
|
|
Die automatische Erstellung von Aufgabengruppen basiert derzeit auf der Aufgabensitzung.
|
|
|
|
\subsection{Kernel\texorpdfstring{$\rightarrow$}{->}user space relay support (formerly relayfs)}
|
|
CONFIG\_RELAY [=y] \textbf{[Y]}\\
|
|
Diese Option aktiviert die Unterstützung für die Relaisschnittstelle in bestimmten Dateisystemen
|
|
(wie debugfs). Sie wurde entwickelt, um einen effizienten Mechanismus für Werkzeuge und Einrichtungen
|
|
zur Weiterleitung großer Datenmengen aus dem Kernelbereich in den Benutzerbereich bereitzustellen.\\
|
|
Wenn Sie unsicher sind, sagen Sie N.
|
|
|
|
\subsection{Initial RAM filesystem and RAM disk (initramfs/initrd) support}
|
|
CONFIG\_BLK\_DEV\_INITRD [=y] \textbf{[Y]}\\
|
|
Das anfängliche RAM-Dateisystem ist ein ramfs, das vom Bootloader (loadlin oder lilo) geladen und vor
|
|
dem normalen Bootvorgang als root eingehängt wird. Es wird typischerweise verwendet, um Module zu laden,
|
|
die zum Einhängen des \glqq echten\grqq{} Root"=Dateisystems benötigt werden, usw.\\
|
|
Siehe $<$file:Documentation/admin-guide/initrd.rst$>$ für Details.
|
|
Wenn die RAM"=Disk"=Unterstützung\\
|
|
(BLK\_DEV\_RAM) eben\-falls enthalten ist, aktiviert dies auch die anfängliche
|
|
RAM"=Disk"=Unterstützung (initrd) und fügt \qty{15}{\kilo\byte} (auf einigen anderen Architekturen mehr) zur Kernelgröße hinzu.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Initramfs source file(s)}
|
|
CONFIG\_INITRAMFS\_SOURCE [=] \textbf{[~]}\\
|
|
Dies kann entweder ein einzelnes cpio-Archiv mit der Endung .cpio oder eine durch Leerzeichen getrennte
|
|
Liste von Verzeichnissen und Dateien zur Erstellung des initramfs-Abbilds sein.
|
|
Ein cpio-Archiv sollte ein Dateisystemarchiv enthalten, das als initramfs-Abbild verwendet werden soll.
|
|
Verzeichnisse sollten ein Dateisystem-Layout enthalten, das in das initramfs-Abbild aufgenommen werden
|
|
soll. Die Dateien sollten Einträge in dem Format enthalten, das vom
|
|
Programm \texttt{usr/gen\_init\_cpio} im Kernelbaum beschrieben wird.
|
|
Wenn mehrere Verzeichnisse und Dateien angegeben werden, wird das initramfs-Abbild die Summe aller
|
|
dieser Verzeichnisse und Dateien sein.\\
|
|
Siehe $<$file:Documentation/driver-api/early-userspace/early\_userspace\_support.rst$>$
|
|
für weitere Details.\\
|
|
Wenn Sie sich nicht sicher sind, lassen Sie das Feld leer.\\
|
|
Symbol: INITRAMFS\_SOURCE [=]\\
|
|
Type : string (Zeichenkette)
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using gzip}
|
|
CONFIG\_RD\_GZIP [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines gzip-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using bzip2}
|
|
CONFIG\_RD\_BZIP2 [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines bzip2-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using LZMA}
|
|
CONFIG\_RD\_LZMA [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines LZMA-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using XZ}
|
|
CONFIG\_RD\_XZ [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines XZ-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using LZO}
|
|
CONFIG\_RD\_LZO [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines LZO-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using LZ4}
|
|
CONFIG\_RD\_LZ4 [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines LZ4-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsubsection{Support initial ramdisk/ramfs compressed using ZSTD}
|
|
CONFIG\_RD\_ZSTD [=y] \textbf{[Y]}\\
|
|
Unterstützung des Ladens eines ZSTD-kodierten Anfangs-Ramdisk-
|
|
oder Cpio-Puffers.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsection{Boot config support}
|
|
CONFIG\_BOOT\_CONFIG [=y] \textbf{[Y]}\\
|
|
Extra boot config ermöglicht es dem Systemadministrator, eine Konfigurationsdatei
|
|
als zusätzliche Erweiterung der Kernel-Cmdline beim Booten zu übergeben.
|
|
Die Bootkonfigurationsdatei muss am Ende von \mbox{initramfs} mit Prüfsumme, Größe und
|
|
magischem Wort angehängt werden.\\
|
|
Siehe $<$file:Documentation/admin-guide/bootconfig.rst$>$ für Details.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
|
|
\subsubsection{Force unconditional bootconfig processing}
|
|
CONFIG\_BOOT\_CONFIG\_FORCE [=n] \textbf{[N]}\\
|
|
Wenn diese Kconfig-Option gesetzt ist, wird die BOOT\_CONFIG-Verarbeitung auch dann
|
|
durchgeführt, wenn der Kernel-Boot-Parameter \texttt{bootconfig} weggelassen wird.
|
|
Tatsächlich gibt es mit dieser Kconfig-Option keine Möglichkeit, den Kernel dazu
|
|
zu bringen, die von BOOT\_CONFIG gelieferten Kernel-Boot-Parameter zu ignorieren.\\
|
|
Wenn Sie unsicher sind, sagen Sie N.
|
|
|
|
\subsubsection{Embed bootconfig file in the kernel}
|
|
CONFIG\_BOOT\_CONFIG\_EMBED [=n] \textbf{[N]}\\
|
|
Eine mit BOOT\_CONFIG\_EMBED\_FILE angegebene bootconfig-Datei in den Kernel einbetten.
|
|
Normalerweise wird die bootconfig-Datei mit dem initrd-Image geladen. Wenn das System
|
|
jedoch initrd nicht unterstützt, hilft Ihnen diese Option, indem sie eine bootconfig-Datei
|
|
beim Erstellen des Kernels einbettet.\\
|
|
Wenn Sie unsicher sind, sagen Sie N.
|
|
|
|
\subsection{Preserve cpio archive mtimes in initramfs}
|
|
CONFIG\_INITRAMFS\_PRESERVE\_MTIME [=y] \textbf{[Y]}\\
|
|
Jeder Eintrag in einem initramfs cpio-Archiv enthält einen mtime-Wert.
|
|
Wenn diese Option aktiviert ist, übernehmen die extrahierten cpio-Einträge diese mtime,
|
|
wobei die mtime-Einstellung des Verzeichnisses aufgeschoben wird, bis nach der
|
|
Erstellung aller untergeordneten Einträge.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subsection{Compiler optimization level \texorpdfstring{$\rightarrow$}{->}}
|
|
Optimierungsgrad des Compilers, Auswahl aus den folgenden zwei Punkten:
|
|
|
|
\subsubsection{Optimize for performance (-O2)}
|
|
CONFIG\_CC\_OPTIMIZE\_FOR\_PERFORMANCE [=y] \textbf{[Y]}\\
|
|
Dies ist die Standardoptimierungsstufe für den Kernel, die mit dem Compiler-Flag \texttt{-O2}
|
|
erstellt wird, um die beste Leistung und die hilfreichsten Warnungen bei der
|
|
Kompilierung zu erhalten.
|
|
|
|
\subsubsection{Optimize for size (-Os)}
|
|
CONFIG\_CC\_OPTIMIZE\_FOR\_SIZE [=n] \textbf{[N]}\\
|
|
Wenn Sie diese Option wählen, wird \texttt{-Os} an Ihren Compiler übergeben,
|
|
was zu einem kleineren Kernel führt.
|
|
|
|
\subsection{Configure standard kernel features (expert users)}
|
|
CONFIG\_EXPERT [=n] \textbf{[~]}\\
|
|
Mit dieser Option können bestimmte Basis-Kerneloptionen und -einstellungen
|
|
deaktiviert oder optimiert werden. Dies ist für spezielle Umgebungen gedacht,
|
|
die einen \glqq Nicht-Standard\grqq{}-Kernel tolerieren können.\\
|
|
Verwenden Sie diese Option nur, wenn Sie wirklich wissen, was Sie tun.
|
|
|
|
\subsubsection{Load all symbols for debugging/ksymoops}
|
|
CONFIG\_KALLSYMS [=y] \textbf{[Y]}\\
|
|
(sichtbar wenn EXPERT [=n])\\
|
|
Geben Sie hier Y ein, damit der Kernel symbolische Absturzinformationen und
|
|
symbolische Stack-Backtraces ausgibt. Dies erhöht die Größe des Kernels etwas,
|
|
da alle Symbole in das Kernel-Image geladen werden müssen.
|
|
|
|
\paragraph{Test the basic functions and performance of kallsyms}$~$\\
|
|
CONFIG\_KALLSYMS\_SELFTEST [=n] \textbf{[N]}\\
|
|
Testen Sie die Grundfunktionen und die Leistung einiger Schnittstellen, wie z.\,B.
|
|
\texttt{kallsyms\_lookup\_name}. Außerdem wird die Kompressionsrate des
|
|
kallsyms-Kompressionsalgorithmus für den aktuellen Symbolsatz berechnet.
|
|
Starten Sie den Selbsttest automatisch nach dem Systemstart.\\
|
|
Es wird empfohlen, \texttt{dmesg | grep kallsyms\_selftest} auszuführen,
|
|
um die Testergebnisse zu sammeln.
|
|
In der letzten Zeile wird \texttt{finish} angezeigt, was bedeutet,
|
|
dass der Test abgeschlossen ist.
|
|
|
|
\paragraph{Include all symbols in kallsyms}$~$\\
|
|
CONFIG\_KALLSYMS\_ALL [=y] \textbf{[Y]}\\
|
|
Normalerweise enthält kallsyms nur die Symbole von Funktionen für schönere
|
|
OOPS-Meldungen und Backtraces (d.\,h. Symbole aus den Abschnitten text und
|
|
inittext). Dies ist für die meisten Fälle ausreichend. Nur wenn Sie Kernel-Live-Patching
|
|
oder andere weniger häufige Anwendungsfälle (z.\,B. wenn ein Debugger verwendet
|
|
wird) aktivieren wollen, sind alle Symbole erforderlich (d.\,h. die Namen von Variablen
|
|
aus den Data-Abschnitten usw.).\\
|
|
Diese Option stellt sicher, dass alle Symbole in das Kernel-Image geladen werden
|
|
(d.\,h. Symbole aus allen Sektionen), was die Kernelgröße erhöht (je nach Kernelkonfiguration
|
|
kann sie \qty{300}{\kibi\byte} oder etwas Ähnliches betragen).\\
|
|
Sagen Sie N, es sei denn, Sie brauchen wirklich alle Symbole,
|
|
oder Kernel-Live-Patching.
|
|
|
|
\subsection{Kernel Performance Events And Counters \texorpdfstring{$\rightarrow$}{->}}
|
|
Kernel"=Leistungsereignisse und -Zähler
|
|
|
|
\subsubsection{Kernel performance events and counters}
|
|
CONFIG\_PERF\_EVENTS [=y] \textbf{[Y]}\\
|
|
Aktivieren Sie die Kernel"=Unterstützung für verschiedene von Software und Hardware
|
|
bereitgestellte Leistungsereignisse.
|
|
|
|
Software-Ereignisse werden entweder integriert oder über die Verwendung von generischen
|
|
Tracepoints unterstützt.
|
|
|
|
Die meisten modernen CPUs unterstützen Leistungsereignisse über Leistungszählerregister.
|
|
Diese Register zählen die Anzahl bestimmter Arten von hw-Ereignissen: z.\,B. ausgeführte
|
|
Anweisungen, erlittene Cachemisses oder falsch vorhergesagte Verzweigungen -- ohne den
|
|
Kernel oder Anwendungen zu verlangsamen. Diese Register können auch Unterbrechungen
|
|
auslösen, wenn eine bestimmte Anzahl von Ereignissen überschritten wird -- und können so
|
|
dazu verwendet werden, ein Profil des Codes zu erstellen, der auf dieser CPU läuft.
|
|
|
|
Das Linux"=Performance"=Event"=Subsystem bietet eine Abstraktion dieser Software- und
|
|
Hardware"=Event"=Fähigkeiten, die über einen Systemaufruf zugänglich sind und von dem
|
|
Dienstprogramm \texttt{perf} in \texttt{tools/perf/} verwendet werden.
|
|
Es stellt Zähler pro Task
|
|
und pro CPU zur Verfügung und bietet darüber hinaus Ereignisfunktionen.\\
|
|
Sagen Sie Y, wenn Sie unsicher sind.
|
|
|
|
\paragraph{Debug: use vmalloc to back perf mmap() buffers}$~$\\
|
|
CONFIG\_DEBUG\_PERF\_USE\_VMALLOC [=n] \textbf{[N]}\\
|
|
Verwendung von vmalloc-Speicher zur Sicherung von mmap()-Puffern.
|
|
Hauptsächlich nützlich zum Debuggen des vmalloc"=Codes auf Plattformen, die dies nicht erfordern.
|
|
Sagen Sie N, wenn Sie unsicher sind.
|
|
|
|
\subsection{Profiling support}
|
|
CONFIG\_PROFILING [=y] \textbf{[Y]}\\
|
|
Sagen Sie hier Y, um die erweiterten Unterstützungsmechanismen für das Profiling zu
|
|
aktivieren, die von Profilern verwendet werden.
|
|
|
|
\subsection{Kexec and crash features \texorpdfstring{$\rightarrow$}{->}}
|
|
Kexec und Absturzmerkmale
|
|
|
|
\subsubsection{Enable kexec system call}
|
|
CONFIG\_KEXEC [=y] \textbf{[Y]}\\
|
|
\texttt{kexec} ist ein Systemaufruf, der die Fähigkeit implementiert, den aktuellen Kernel
|
|
herunterzufahren und einen anderen Kernel zu starten. Es ist wie ein Neustart, aber er ist
|
|
unabhängig von der System-Firmware. Und wie ein Neustart können Sie damit jeden Kernel
|
|
starten, nicht nur Linux.
|
|
Der Name kommt von der Anlehnung mit dem Systemaufruf \texttt{exec}.
|
|
Es ist ein fortlaufender Prozess, um sicher zu sein, dass die Hardware eines Rechners
|
|
ordnungsgemäß heruntergefahren wird, seien Sie also nicht überrascht, wenn dieser Code bei
|
|
Ihnen zunächst nicht funktioniert. Zum Zeitpunkt des Verfassens dieses Artikels ist die
|
|
genaue Hardwareschnittstelle noch stark im Wandel, so dass keine gute Empfehlung
|
|
ausgesprochen werden kann.
|
|
|
|
\subsubsection{Enable kexec file based system call}
|
|
CONFIG\_KEXEC\_FILE [=y] \textbf{[Y]}\\
|
|
(Aktivieren des dateibasierten Systemaufrufs kexec)\\
|
|
Dies ist eine neue Version des Systemaufrufs \texttt{kexec}. Dieser Systemaufruf ist dateibasiert und
|
|
nimmt Dateideskriptoren als Systemaufrufsargument für Kernel und initramfs anstelle einer Liste
|
|
von Segmenten, wie sie vom kexec-Systemaufruf akzeptiert wird.
|
|
|
|
\paragraph{Verify kernel signature during kexec\_file\_load() syscall}$~$\\
|
|
CONFIG\_KEXEC\_SIG [=y] \textbf{[Y]}\\
|
|
Mit dieser Option wird der Syscall \texttt{kexec\_file\_load()} auf eine gültige Signatur des
|
|
Kernel-Images geprüft. Das Image kann immer noch ohne gültige Signatur geladen werden, es sei denn,
|
|
Sie aktivieren auch KEXEC\_SIG\_FORCE, aber wenn es eine Signatur gibt, die überprüft werden kann,
|
|
dann muss sie auch gültig sein.
|
|
Zusätzlich zu dieser Option müssen Sie die Signaturprüfung für den entsprechenden Kernel"=Image"=Typ,
|
|
der geladen wird, aktivieren, damit dies funktioniert.
|
|
|
|
\subparagraph{Require a valid signature in kexec\_file\_load() syscall}$~$\\
|
|
CONFIG\_KEXEC\_SIG\_FORCE [=n] \textbf{[N]}\\
|
|
Diese Option macht die Überprüfung der Kernelsignatur für den Syscall
|
|
\texttt{kexec\_file\_load()} zwingend erforderlich.
|
|
|
|
\subparagraph{Enable bzImage signature verification support}$~$\\
|
|
CONFIG\_KEXEC\_BZIMAGE\_VERIFY\_SIG [=n] \textbf{[N]}\\
|
|
Aktivierung der Unterstützung von bzImage für die Signaturprüfung.
|
|
|
|
\subsubsection{kexec jump}
|
|
CONFIG\_KEXEC\_JUMP [=y] \textbf{[Y]}\\
|
|
Sprung zwischen Original-Kernel und kexeced-Kernel und Aufruf von Code im physikalischen
|
|
Adressmodus über KEXEC
|
|
|
|
\subsubsection{kexec crash dumps}
|
|
CONFIG\_KEXEC\_DUMP [=y] \textbf{[Y]}\\
|
|
Absturzdump (Speicherauszug) erzeugen, nachdem er von kexec gestartet wurde.
|
|
Dies sollte normalerweise nur in speziellen Crash-Dump-Kerneln gesetzt werden, die im Hauptkernel
|
|
mit kexec-tools in einen speziell reservierten Bereich geladen werden und dann später nach einem
|
|
Absturz von kdump/kexec ausgeführt werden. Der Crash-Dump-Kernel muss mit PHYSICAL\_START auf eine
|
|
Speicheradresse kompiliert werden, die nicht vom Hauptkernel oder BIOS verwendet wird, oder er muss
|
|
als relocatable image (CONFIG\_RELOCATABLE=y) erstellt werden.\\
|
|
Für weitere Details siehe Documentation/admin-guide/kdump/kdump.rst
|
|
|
|
Für s390 aktiviert diese Option auch zfcpdump.\\
|
|
Siehe auch $<$file:Documentation/s390/zfcpdump.rst$>$
|
|
|
|
\paragraph{Update the crash elfcorehdr on system configuration changes}$~$\\
|
|
CONFIG\_CRASH\_HOTPLUG [=y] \textbf{[Y]}\\
|
|
Aktivierung der direkten Aktualisierung der Crash-Elfcorehdr (die die Liste der CPUs und
|
|
Speicherbereiche enthält, die bei einem Absturz gelöscht werden sollen) als Reaktion auf
|
|
Hot-Plug/Unplug oder Online/Offline von CPUs oder Speicher. Dies ist ein sehr viel
|
|
fortschrittlicherer Ansatz als der Versuch dies im Userspace zu tun.\\
|
|
Wenn Sie unsicher sind, sagen Sie Y.
|
|
|
|
\subparagraph{Specify the maximum number of memory regions for the elfcorehdr}$~$\\
|
|
CONFIG\_CRASH\_MAX\_MEMORY\_RANGES [=8192] \textbf{[8192]}\\
|
|
Für den Pfad des Systemaufrufs \texttt{kexec\_file\_load()} ist die maximale Anzahl
|
|
der Speicherbereiche anzugeben, die der elfcorehdr-Puffer/das elfcorehdr-Segment aufnehmen kann.
|
|
Diese Regionen werden über \texttt{walk\_system\_ram\_res()} ermittelt, z.\,B. die
|
|
'System RAM'-Einträge in /proc/iomem. Dieser Wert wird mit NR\_CPUS\_DEFAULT kombiniert und mit
|
|
\texttt{sizeof(Elf64\_Phdr)} multipliziert, um die endgültige elfcorehdr-Speicherpuffer-/Segmentgröße
|
|
zu bestimmen. Der Wert 8192 beispielsweise deckt ein (dünn besiedeltes) 1TiB-System ab,
|
|
das aus 128MiB-Memblöcken besteht, und führt zu einer elfcorehdr-Speicher\-puffer-/Segmentgröße
|
|
von unter 1MiB. Dies ist eine vernünftige Wahl, um sowohl Baremetal- als auch virtuelle
|
|
Maschinenkonfigurationen zu unterstützen.\\
|
|
Für den Syscall-Pfad \texttt{kexec\_load()}
|
|
ist CRASH\_MAX\_MEMORY\_RANGES Teil der Berechnung hinter dem Wert,
|
|
der über das Attribut /sys/kernel/crash\_elfcorehdr\_size bereitgestellt wird.
|