\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 [=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. %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.