Files
kernel_dell_tom/documentation/linux_configuration.tex
2023-11-30 23:22:53 +01:00

749 lines
40 KiB
TeX

%
% Thomas Kuschel 2023
\newcommand{\version}{V6.6}
\documentclass[10pt,a4paper]{article}
%\documentclass[12pt,a4paper]{report}
\usepackage[a4paper,margin=25mm]{geometry}
\usepackage[ngerman]{babel} %Verwendung von \glqq \qrgg{}
\usepackage{hyperref}
\setcounter{secnumdepth}{5}%numbering down to paragraphs, subparagraphs
%% \usepackage{ulem} %strike through with /sout{}
% you have to install texlive-plaingeneric first :
\usepackage{ulem}
% The following is to use subparagraph without intending:
\makeatletter
\renewcommand\subparagraph{%
\@startsection {subparagraph}{5}{\z@ }{3.25ex \@plus 1ex
\@minus .2ex}{-1em}{\normalfont \normalsize \bfseries }}%
\makeatother
\begin{document}
\section*{Linux Configuration \version}
\subsection{Einführung}
Dieses Dokument dient zur Beschreibung von diversen Einstellungen
bei der Konfiguration mittels \texttt{ make menuconfig } unter Linux.\\
Es wird nicht näher darauf eingegangen, wie der Kernel kompiliert wird
oder welche Voreinstellungen, Programme etc. zum Kompilieren benötigt
werden.\\
Zu Beginn der jeweiligen Konfigurationszeile wird der Standardwert
(Default) angezeigt. Mein Vorschlag folgt danach.\\
Z.\,B. bei CONFIG\_WERROR~[=n]~\textbf{[Y]}\\
Hier ist der Standarwert ein Nein [n], meine persönliche Einstellung ein Ja [Y].\\[0.5em]
\textit{\copyright KW4NZ, Thomas Kuschel\\Wenn Sie Tippfehler finden oder Korrekturen wünschen,
dann schicken Sie dies mit Erläuterungen und dem Hinweis auf die obenstehende
Version \version ~an:
\href{mailto:oe1tkt@gmail.com}{oe1tkt@gmail.com}}
%\section{General setup \( \rightarrow \) }
\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 [=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
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.
\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.
\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 Distros
\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 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 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
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.
\subsubsection{LZO}
CONFIG\_KERNEL\_LZO [=n] \textbf{[~]}\\
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.
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 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 init= nicht übergeben wird.
\subsection{Default hostname}
CONFIG\_DEFAULT\_HOSTNAME [=archlinux] \textbf{[=archlinux]}\\
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.
\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 mq\_\*) 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 [=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
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.
\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!\\
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-Anweisungen 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 [=n] \textbf{[N]}\\
Diese Einstellung reduziert die Latenz des Kernels durch zusätzliche "explizite Unterbrechungspunkte" 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 [=y] \textbf{[Y]}\\
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:
- Entschärfung einiger (nicht aller) SMT-Seitenkanäle;
- Begrenzung der SMT-Interferenz zur Verbesserung des Determinismus und/oder der Leistung.\\
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.
\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
\textless{}http://www.gnu.org/software/acct/\textgreater{} 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 Aufgaben/Prozessen 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-Kapazitä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 Druckstauinformationen
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. Webserver, 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 "Störquellen" wie ungebundene Workqueues, Timers,
kthreads usw. gestört werden.\\
Ungebundene Aufgaben werden auf Housekeeping-CPUs verlagert.
Dies wird durch den Boot-Parameter "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 "make oldconfig" 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)\\
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 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)\\
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 kheaders.ko erstellt, das bei Bedarf
geladen werden kann, um Zugriff auf die Header zu erhalten.
\end{document}