UPD CMS debug messages

documentation/linux_configuration.tex

@@ -3889,4 +3889,204 @@ Dies kann auch zu unterschiedlichen Konfigurationen des Pools führen, da zsmall
 ähnlichen Eigenschaften zusammenführt.\\
 Weitere Informationen finden Sie in der Dokumentation zu zsmalloc.
 
+\subsection{SLAB allocator options \texorpdfstring{$\rightarrow$}{->}}
+
+\subsubsection{Choose SLAB allocator (SLUB (Unqueued Allocator)) \texorpdfstring{$\rightarrow$}{->}}
+Diese Option ermöglicht die Auswahl eines Slab-Allokators.
+
+\paragraph{SLAB (DEPRECATEDUnqueued Allocator)}$~$\\
+CONFIG\_SLAB\_DEPRECATED [=n] \textbf{[N]}\\
+Veraltet und soll in ein paar Zyklen entfernt werden. Ersetzt durch SLUB. Wenn Sie nicht auf SLUB umsteigen
+können, wenden Sie sich bitte an linux-mm@kvack.org und an die Personen, die im Abschnitt SLAB ALLOCATOR der
+MAINTAINERS-Datei aufgeführt sind, und erläutern Sie die Gründe. Der reguläre Slab-Allokator, der sich
+bewährt hat und bekanntermaßen in allen Umgebungen gut funktioniert. Er organisiert Cache-Hot-Objekte in
+Warteschlangen pro CPU und pro Knoten.
+
+\paragraph{SLUB (Unqueued Allocator)}$~$\\
+CONFIG\_SLUB [=y] \textbf{[Y]}\\
+SLUB ist ein Slab-Allokator, der die Nutzung von Cache-Zeilen minimiert, anstatt Warteschlangen von gecachten
+Objekten zu verwalten (SLAB-Ansatz). Die Zwischenspeicherung pro CPU wird durch Slabs von Objekten anstelle
+von Objekt-Warteschlangen realisiert. SLUB kann den Speicher effizient nutzen und verfügt über verbesserte
+Diagnosefunktionen. SLUB ist die Standardwahl für einen Slab-Allokator.
+
+\subsubsection{Allow slab caches to be merged}
+CONFIG\_SLAB\_MERGE\_DEFAULT [=y] \textbf{[Y]}\\
+Um die Fragmentierung des Kernspeichers zu verringern, können Slab-Caches zusammengelegt werden, wenn sie
+die gleiche Größe und andere Merkmale aufweisen. Dies birgt das Risiko, dass Kernel-Heap-Überläufe Objekte
+aus zusammengeführten Caches überschreiben können (und das Cache-Layout leichter zu kontrollieren ist),
+wodurch solche Heap-Angriffe von Angreifern leichter ausgenutzt werden können. Wenn die Caches nicht gemischt
+werden, können diese Arten von Angriffen normalerweise nur Objekte im selben Cache beschädigen. Um die
+Zusammenführung zur Laufzeit zu deaktivieren, kann \texttt{slab\_nomerge} in der Kernel-Befehlszeile
+übergeben werden.
+
+\subsubsection{Randomize slab freelist}
+CONFIG\_SLAB\_FREELIST\_RANDOM [=y] \textbf{[Y]}\\
+Die Reihenfolge der Freelist bei der Erstellung neuer Seiten wird zufällig festgelegt.
+Dieses Sicherheitsmerkmal verringert die Vorhersagbarkeit der Kernel-Slab-Zuweisung gegen Heap-Überläufe.
+
+\subsubsection{Harden slab freelist metadata}
+CONFIG\_SLAB\_FREELIST\_HARDENED [=y] \textbf{[Y]}\\
+Viele Kernel-Heap-Angriffe zielen auf Slab-Cache-Metadaten und andere Infrastrukturen ab.
+Diese Optionen bringen geringfügige Leistungseinbußen mit sich, um den Kernel-Slab-Allokator gegen gängige
+Freelist-Angriffsmethoden zu härten. Einige Slab-Implementierungen haben mehr Sanity-Checking als andere.
+Diese Option ist am effektivsten mit CONFIG\_SLUB.
+
+\subsubsection{Enable SLUB performance statistics}
+CONFIG\_SLUB\_STATS [=n] \textbf{[N]}\\
+SLUB-Statistiken sind nützlich, um das Zuweisungsverhalten von SLUBs zu debuggen und Wege zur Optimierung
+der Zuweisungsfunktion zu finden. Diese Funktion sollte niemals für den produktiven Einsatz aktiviert werden,
+da die Führung von Statistiken die Zuweisungsfunktion um einige Prozentpunkte verlangsamt.
+Der Befehl \texttt{slabinfo} unterstützt die Ermittlung der aktivsten Slabs, um herauszufinden,
+welche Slabs für eine bestimmte Last relevant sind. Versuchen Sie Folgendes: \texttt{slabinfo -DA}
+
+\subsubsection{SLUB per cpu partial cache}
+CONFIG\_SLUB\_CPU\_PARTIAL [=y] \textbf{[Y]}\\
+Partielle Zwischenspeicher pro CPU beschleunigen die Zuweisung und Freigabe von Objekten, die lokal auf einem
+Prozessor liegen, zum Preis einer größeren Unbestimmtheit bei der Latenzzeit der Freigabe. Bei Überlauf
+werden diese Caches geleert, was das Einnehmen von Sperren erfordert, die Latenzspitzen verursachen können.
+Normalerweise würde man sich bei einem Echtzeitsystem für nein entscheiden.
+
+\subsubsection{Randomize slab caches for normal kmalloc}
+CONFIG\_RANDOM\_KMALLOC\_CACHES [=n] \textbf{[N]}\\
+Eine Härtungsfunktion, die mehrere Kopien von Slab-Caches für die normale kmalloc-Allokation erstellt und
+kmalloc veranlasst, eine zufällig auf der Grundlage der Code-Adresse auszuwählen, was es Angreifern
+erschwert, verwundbare Speicherobjekte auf den Heap zu sprühen, um Speicherschwachstellen auszunutzen.
+Gegenwärtig ist die Anzahl der Kopien auf 16 festgelegt, ein angemessen großer Wert, der die für verschiedene
+Subsysteme oder Module zugewiesenen Speicherobjekte effektiv in verschiedene Caches aufteilt, und zwar auf
+Kosten eines begrenzten Grades an Speicher- und CPU-Overhead, der mit der Hardware und der Systemauslastung
+zusammenhängt.
+
+\subsection{Page allocator randomization}
+CONFIG\_SHUFFLE\_PAGE\_ALLOCATOR [=y] \textbf{[Y]}\\
+Die Randomisierung der Seitenzuweisung verbessert die durchschnittliche Auslastung eines direkt abgebildeten
+Memory-Side-Cache. In Abschnitt 5.2.27 Heterogeneous Memory Attribute Table (HMAT) der ACPI 6.2a-Spezifikation
+finden Sie ein Beispiel dafür, wie eine Plattform das Vorhandensein eines speicherseitigen Cache anzeigt.
+Es gibt auch zufällige Sicherheitsvorteile, da es die Vorhersagbarkeit von Seitenzuweisungen reduziert, um
+SLAB\_FREELIST\_RANDOM zu ergänzen, aber die Standardgranularität des Shufflings auf MAX\_ORDER,
+d.h. die 10. Reihenfolge der Seiten wird auf der Grundlage der Cache-Nutzung auf x86 ausgewählt.
+Die Randomisierung verbessert zwar die Cache-Nutzung, kann sich aber auf Plattformen ohne Cache negativ auf
+die Arbeitslast auswirken. Aus diesem Grund wird die Randomisierung standardmäßig nur aktiviert, wenn zur
+Laufzeit ein direkt zugeordneter Memory-Side-Cache erkannt wird. Andernfalls kann die Randomisierung mit dem
+Kernel-Befehlszeilenparameter \texttt{page\_alloc.shuffle} zwangsweise aktiviert werden.
+Sagen Sie Y, wenn Sie unsicher sind.
+
+\subsection{Disable heap randomization}
+CONFIG\_COMPAT\_BRK [=n] \textbf{[N]}\\
+Die Randomisierung der Heap-Platzierung macht Heap-Exploits schwieriger, aber sie macht auch alte
+Binärdateien (einschließlich aller libc5-basierten) kaputt. Diese Option ändert die Standardeinstellung beim
+Booten auf Heap-Randomisierung deaktiviert und kann zur Laufzeit überschrieben werden, indem
+/proc/sys/kernel/randomize\_va\_space auf 2 gesetzt wird. Auf nicht-alten Distributionen (nach 2000)
+ist N normalerweise eine sichere Wahl.
+
+\subsection{Sparse Memory virtual memmap}
+CONFIG\_SPARSEMEM\_VMEMMAP [=y] \textbf{[Y]}\\
+SPARSEMEM\_VMEMMAP verwendet eine virtuell gemappte Memmap, um texttt{pfn\_to\_page} und\\
+\texttt{page\_to\_pfn} Operationen zu optimieren.
+Dies ist die effizienteste Option, wenn genügend Kernel-Res\-sour\-cen verfügbar sind.
+
+\subsection{Memory hotplug \texorpdfstring{$\rightarrow$}{->}}
+CONFIG\_HOTPLUG [=y] \textbf{[Y]}\\
+\textit{Für diese Option gibt es keine Hilfe.}
+
+\subsubsection{Online the newly added memory blocks by default}
+CONFIG\_MEMORY\_HOTPLUG\_DEFAULT\_ONLINE [=y] \textbf{[Y]}\\
+Diese Option legt die Standardeinstellung für die Hotplug-Onlining-Richtlinie für Speicher\\
+(/sys/devices/system/memory/auto\_online\_blocks) fest, die bestimmt, was mit neu hinzugefügten
+Spei\-cher\-be\-reichen geschieht.
+Die Richtlinieneinstellung kann jederzeit zur Laufzeit geändert werden.\\
+Siehe Documentation/admin-guide/mm/memory-hotplug.rst für weitere Informationen.
+Geben Sie hier Y an, wenn Sie möchten, dass alle Hotplug-Speicherblöcke standardmäßig im
+\glqq Online\grqq{}-Zustand erscheinen. Geben Sie hier N an, wenn Sie möchten, dass die
+Standardrichtlinie alle Hot-Plugged-Speicherblöcke im \glqq Offline\grqq{}-Zustand hält.
+
+\subsubsection{Allow for memory hot remove}
+CONFIG\_MEMORY\_HOTREMOVE [=y] \textbf{[Y]}\\
+\textit{Für diese Option gibt es keine Hilfe.}
+
+\subsection{Allow for balloon memory compaction/migration}
+CONFIG\_BALLOON\_COMPACTION [=y] \textbf{[Y]}\\
+Die durch das Ballooning verursachte Speicherfragmentierung kann die Anzahl der zusammenhängenden
+2-MB-Speicher\-blöcke, die in einem Gastsystem verwendet werden können, erheblich verringern, was zu
+Leistungseinbußen aufgrund der geringeren Anzahl transparenter großer Seiten führt, die vom Gastsystem
+verwendet werden können. Das Zulassen der Verdichtung und Migration für Speicherseiten, die als Teil von
+Speicher-Ballon-Geräten eingetragen sind, vermeidet das oben beschriebene Szenario und trägt zur Verbesserung
+der Speicherdefragmentierung bei.
+
+\subsection{Allow for memory compaction}
+CONFIG\_COMPACTION [=y] \textbf{[Y]}\\
+Die Verdichtung ist die einzige Speicherverwaltungskomponente, die zuverlässig Speicherblöcke hoher Ordnung
+(größere, physisch zusammenhängende Blöcke) bildet. Die Seitenzuweisung ist in hohem Maße auf die Verdichtung
+angewiesen, und das Fehlen dieser Funktion kann bei Speicheranforderungen hoher Ordnung zu unerwarteten
+OOM-Killer-Aufrufen führen. Sie sollten diese Option nicht deaktivieren, es sei denn, es gibt wirklich einen
+triftigen Grund dafür, und dann wären wir sehr daran interessiert, diesen unter
+\href{mailto:linux-mm@kvack.org}{linux-mm@kvack.org} zu erfahren.
+
+\subsection{Free page reporting}
+CONFIG\_PAGE\_REPORTING [=y] \textbf{[Y]}\\
+Die Meldung freier Seiten ermöglicht die inkrementelle Erfassung freier Seiten vom Buddy-Allokator mit
+dem Ziel, diese Seiten einer anderen Einheit, z.~B. einem Hypervisor, zu melden, damit der Speicher
+innerhalb des Hosts für andere Zwecke freigegeben werden kann.
+
+\subsection{Page migration}
+CONFIG\_MIGRATION [=y] \textbf{[Y]}\\
+Ermöglicht die Migration des physischen Standorts von Seiten von Prozessen, während die virtuellen
+Adressen nicht geändert werden. Dies ist in zwei Situationen nützlich. Erstens auf NUMA-Systemen, um
+Seiten näher an die zugreifenden Prozessoren zu bringen. Zweitens bei der Zuweisung großer Seiten,
+da durch die Migration Seiten verlagert werden können, um eine große Seitenzuweisung zu erfüllen,
+anstatt sie zurückzufordern.
+
+\subsection{Enable KSM for page merging}
+CONFIG\_KSM [=y] \textbf{[Y]}\\
+Aktivieren Sie Kernel Samepage Merging: KSM scannt in regelmäßigen Abständen die Bereiche des Adressraums
+einer Anwendung, die laut einer Anwendung zusammengeführt werden können. Wenn er Seiten mit identischem
+Inhalt findet, ersetzt er die vielen Instanzen durch eine einzige Seite mit diesem Inhalt und spart so
+Speicher, bis eine oder eine andere Anwendung den Inhalt ändern muss. Empfohlen für die Verwendung mit KVM
+oder mit anderen doppelten Anwendungen.\\
+Siehe Documentation/mm/ksm.rst für weitere Informationen: KSM ist inaktiv, bis ein Programm festgestellt hat,
+dass ein Bereich MADV\_MERGEABLE ist, und root /sys/kernel/mm/ksm/run auf 1 gesetzt hat
+(wenn CONFIG\_SYSFS gesetzt ist).
+
+\subsection{Low address space to protect from user allocation}
+CONFIG\_DEFAULT\_MMAP\_MIN\_ADDR [=65536] \textbf{[65536]}\\
+Dies ist der Teil des niedrigen virtuellen Speichers, der vor der Zuweisung an den Benutzerraum geschützt werden
+sollte. Wenn ein Benutzer davon abgehalten wird, auf niedrige Seiten zu schreiben, kann dies dazu beitragen, die
+Auswirkungen von NULL-Zeiger-Fehlern im Kernel zu verringern. Für die meisten ia64-, ppc64- und x86-Benutzer mit
+viel Adressraum ist ein Wert von 65536 angemessen und sollte keine Probleme verursachen.
+Auf Arm und anderen Archs sollte er nicht höher als 32768 sein. Programme, die die vm86-Funktionalität nutzen oder
+diesen niedrigen Adressraum abbilden müssen, benötigen CAP\_SYS\_RAWIO oder deaktivieren diesen Schutz,
+indem sie den Wert auf 0 setzen. Dieser Wert kann nach dem Booten mit dem Parameter /proc/sys/vm/mmap\_min\_addr
+geändert werden.
+
+\subsection{Enable recovery from hardware memory errors}
+CONFIG\_MEMORY\_FAILURE [=y] \textbf{[Y]}\\
+Ermöglicht die Wiederherstellung von Code nach einigen Speicherfehlern auf Systemen mit MCA-Wiederherstellung.
+Dadurch kann ein System auch dann weiterlaufen, wenn ein Teil des Speichers unkorrigierte Fehler aufweist. Dies
+erfordert spezielle Hardwareunterstützung und in der Regel ECC-Speicher.
+
+\subsection{HWPoison pages injector}
+CONFIG\_HWPOISON\_INJECT [=m] \textbf{[M]}\\
+\textit{Für diese Option gibt es keine Hilfe.}
+
+\subsection{Transparent Hugepage Support}
+CONFIG\_TRANSPARENT\_HUGEPAGE [=y] \textbf{[Y]}\\
+Transparent Hugepages erlaubt es dem Kernel, große Seiten und große tlb transparent für die Anwendungen zu
+verwenden, wann immer dies möglich ist. Diese Funktion kann die Rechenleistung bestimmter Anwendungen verbessern,
+indem sie Seitenfehler bei der Speicherzuweisung beschleunigt, die Anzahl der tlb-Misses verringert und das
+Durchlaufen der Seitentabelle beschleunigt.
+Wenn der Speicher bei eingebetteten Systemen begrenzt ist, können Sie N angeben.
+
+\subsection{Contiguous Memory Allocator}
+CONFIG\_CMA [=y] \textbf{[Y]}\\
+Dadurch wird der Contiguous Memory Allocator aktiviert, der es anderen Subsystemen ermöglicht, große, physisch
+zusammenhängende Speicherblöcke zuzuweisen. CMA reserviert einen Speicherbereich und erlaubt nur die Zuweisung
+beweglicher Seiten aus diesem Bereich. Auf diese Weise kann der Kernel den Speicher als Pagecache verwenden,
+und wenn ein Subsystem einen zusammenhängenden Bereich anfordert, werden die zugewiesenen Seiten verschoben,
+um die zusammenhängende Anforderung zu bedienen. Wenn Sie unsicher sind, sagen Sie N für nein.
+
+\subsubsection{CMS debug messages (DEVELOPMENT)}
+CONFIG\_CMA\_DEBUG [=n] \textbf{[N]}\\
+Schaltet Debug-Meldungen in CMA ein. Dies erzeugt KERN\_DEBUG-Meldungen für jeden CMA-Aufruf sowie verschiedene
+Meldungen während der Verarbeitung von Aufrufen wie dma\_alloc\_from\_contiguous(). Diese Option hat keinen
+Einfluss auf Warn- und Fehlermeldungen.
+
 \end{document}