UPD section 01, beautify
This commit is contained in:
@@ -14,7 +14,7 @@ trotzdem kompilieren und testen.
|
||||
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 '-Werror' (für C) und '-Dwarnings' (für Rust) um diese Regel
|
||||
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
|
||||
@@ -36,16 +36,17 @@ 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.\\
|
||||
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
|
||||
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.)
|
||||
@@ -81,36 +82,42 @@ 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
|
||||
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 33~\% weniger als mit GZIP.
|
||||
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 Komprimierungsverhältnis des ausführbaren
|
||||
Codes verbessern können. Die Größe des Kernels ist mit XZ im
|
||||
Vergleich zu GZIP etwa 30~\% kleiner. Auf Architekturen, für die
|
||||
Vergleich zu GZIP etwa $\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 10~\% größer als GZIP.
|
||||
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.\\
|
||||
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. 8~\% größere Kernelgröße als bei LZO.
|
||||
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}
|
||||
@@ -124,11 +131,11 @@ 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.
|
||||
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 init= nicht übergeben wird.
|
||||
wird einfach die Fallback-Liste verwendet, wenn \texttt{init=} nicht übergeben wird.
|
||||
|
||||
\subsection{Default hostname}
|
||||
CONFIG\_DEFAULT\_HOSTNAME [=archlinux] \textbf{[=archlinux]}\\
|
||||
@@ -145,14 +152,15 @@ aus Bibliotheksfunktionen (libraries) und Systemaufrufen die Prozesse (laufende
|
||||
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
|
||||
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
|
||||
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}
|
||||
@@ -172,7 +180,7 @@ 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.
|
||||
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.\\
|
||||
@@ -253,12 +261,12 @@ 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.
|
||||
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
|
||||
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.
|
||||
@@ -279,7 +287,7 @@ 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.\\
|
||||
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)}\\
|
||||
@@ -287,7 +295,7 @@ Beachten Sie, dass ein Administrator diese Funktion durch Ändern aktivieren sol
|
||||
|
||||
\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
|
||||
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
|
||||
@@ -306,15 +314,15 @@ Wenn Sie unsicher sind, wie Sie diese Frage beantworten sollen, antworten Sie mi
|
||||
\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
|
||||
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,
|
||||
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]}\\
|
||||
@@ -352,11 +360,11 @@ Rechenleistung einher.
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
@@ -373,17 +381,17 @@ 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
|
||||
Wenn diese Option aktiviert ist -- siehe prctl
|
||||
(PR\_SCHED\_CORE)
|
||||
- stellt die Aufgabenauswahl sicher, dass alle SMT-Geschwister
|
||||
-- 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.\\
|
||||
\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
|
||||
@@ -393,11 +401,11 @@ haben.
|
||||
|
||||
\subsubsection{Cputime accounting (Full dynticks CPU time accounting) \texorpdfstring{$\rightarrow$}{->}}
|
||||
\paragraph{Full dynticks CPU time accounting} $~$\\
|
||||
CONFIG\_VIRT\_CPU\_ACCOUNTING\_GEN [=y] \textbf{[Y]}\\
|
||||
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.
|
||||
Full"=Dynticks"=Systemen zu aktivieren.
|
||||
Diese Berechnung wird durch die Überwachung aller Kernel-Benutzer-Grenzen mithilfe des
|
||||
Kontextverfolgungs-Subsystems implementiert.\\
|
||||
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.
|
||||
@@ -407,7 +415,7 @@ 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
|
||||
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.
|
||||
|
||||
@@ -500,20 +508,20 @@ 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 \glqq isolcpus=\grqq{} gesteuert.\\
|
||||
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
|
||||
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.\\
|
||||
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.
|
||||
|
||||
@@ -529,16 +537,16 @@ 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
|
||||
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
|
||||
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,
|
||||
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.
|
||||
|
||||
@@ -561,25 +569,25 @@ 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
|
||||
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.
|
||||
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
|
||||
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.
|
||||
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)\\
|
||||
@@ -588,8 +596,8 @@ 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
|
||||
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.
|
||||
@@ -708,15 +716,15 @@ 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]}\\
|
||||
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
|
||||
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]}\\
|
||||
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
|
||||
@@ -770,7 +778,7 @@ 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$}{->}}
|
||||
Scheduler-Funktionen
|
||||
\textit{(Scheduler-Funktionen)}
|
||||
|
||||
\subsubsection{Enable utilization clamping for RT/FAIR tasks}
|
||||
CONFIG\_UCLAMP\_TASK [=y] \textbf{[Y]}\\
|
||||
@@ -792,20 +800,21 @@ 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 20 \% Auslastung verfolgen. Eine um 25 \% gesteigerte Aufgabe
|
||||
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 25 \%.
|
||||
Wenn eine zweite, um 30 \% erhöhte Aufgabe auf derselben CPU eingeplant wird,
|
||||
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 30 \%.
|
||||
Der effektive Klemmwert eines Bereichs wird auf seinen Nennwert (20 \% im
|
||||
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 25 \%-Aufgabe auf 30 \% angehoben, bis sie die CPU verlässt.
|
||||
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
|
||||
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.
|
||||
@@ -815,18 +824,20 @@ 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.
|
||||
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.
|
||||
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.
|
||||
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)
|
||||
@@ -838,7 +849,7 @@ 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
|
||||
\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.\\
|
||||
@@ -869,8 +880,8 @@ 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.
|
||||
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}$~$\\
|
||||
@@ -889,13 +900,13 @@ Weitere Informationen finden Sie unter Documentation/scheduler/sched-bwc.rst.
|
||||
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.\\
|
||||
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.
|
||||
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,
|
||||
@@ -903,8 +914,8 @@ 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.\\
|
||||
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}
|
||||
@@ -914,7 +925,7 @@ 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.
|
||||
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.
|
||||
@@ -936,21 +947,21 @@ 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 HugeTLB keine Seitenrückforderung unterstützt, bedeutet die Durchsetzung
|
||||
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.
|
||||
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.\\
|
||||
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}$~$\\
|
||||
@@ -969,7 +980,7 @@ die ein Prozess in der cgroup mknod oder öffnen kann.
|
||||
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.
|
||||
CPU"=Verbrauchs der Tasks in einer cgroup an.
|
||||
|
||||
\subsubsection{Perf controller}
|
||||
CONFIG\_CGROUP\_PERF [=y] \textbf{[Y]}\\
|
||||
@@ -986,7 +997,7 @@ 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.
|
||||
auf dem Ingress"=Pfad von inet"=Sockets ausgeführt.
|
||||
|
||||
\subsubsection{Misc resource controller}
|
||||
CONFIG\_CGROUP\_MISC [=y] \textbf{[Y]}\\
|
||||
@@ -994,13 +1005,13 @@ 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.\\
|
||||
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.
|
||||
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.
|
||||
|
||||
@@ -1014,8 +1025,8 @@ Namensräumen verwendet werden.
|
||||
|
||||
\subsubsection{UTS namespace}
|
||||
CONFIG\_UTS\_NS [=y] \textbf{[Y]}\\
|
||||
In diesem Namensraum sehen Aufgaben verschiedene Informationen, die mit dem Systemaufruf uname()
|
||||
bereitgestellt werden
|
||||
In diesem Namensraum sehen Aufgaben verschiedene Informationen, die mit dem Systemaufruf
|
||||
\texttt{uname()} bereitgestellt werden.
|
||||
|
||||
\subsubsection{TIME namespace}
|
||||
CONFIG\_TIME\_NS [=y] \textbf{[Y]}\\
|
||||
@@ -1029,7 +1040,7 @@ 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,
|
||||
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,
|
||||
@@ -1058,16 +1069,16 @@ Ermöglicht es dem Benutzer, scheinbar mehrere Instanzen des Netzwerkstapels zu
|
||||
\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 /proc-Dateisystemeinträge hinzu.\\
|
||||
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,
|
||||
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.
|
||||
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)}
|
||||
@@ -1081,11 +1092,11 @@ Wenn Sie unsicher sind, sagen Sie N.
|
||||
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.\\
|
||||
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-Unter\-stützung\\
|
||||
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 15 KByte (auf einigen anderen Architekturen mehr) zur Kernelgröße hinzu.\\
|
||||
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)}
|
||||
@@ -1159,7 +1170,7 @@ 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 "bootconfig" weggelassen wird.
|
||||
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.
|
||||
@@ -1229,16 +1240,16 @@ wird) aktivieren wollen, sind alle Symbole erforderlich (d.~h. die Namen von Var
|
||||
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 300KiB oder etwas Ähnliches betragen).\\
|
||||
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
|
||||
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
|
||||
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
|
||||
@@ -1251,8 +1262,8 @@ Kernel oder Anwendungen zu verlangsamen. Diese Register können auch Unterbrechu
|
||||
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
|
||||
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.\\
|
||||
@@ -1260,7 +1271,8 @@ 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.
|
||||
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}
|
||||
@@ -1297,7 +1309,7 @@ Mit dieser Option wird der Syscall \texttt{kexec\_file\_load()} auf eine gültig
|
||||
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,
|
||||
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}$~$\\
|
||||
|
||||
Reference in New Issue
Block a user