diff --git a/documentation/linux_configuration.pdf b/documentation/linux_configuration.pdf
index 4a391c6..82227ac 100644
Binary files a/documentation/linux_configuration.pdf and b/documentation/linux_configuration.pdf differ
diff --git a/documentation/linux_configuration.tex b/documentation/linux_configuration.tex
index fa4129a..019bbe6 100644
--- a/documentation/linux_configuration.tex
+++ b/documentation/linux_configuration.tex
@@ -745,5 +745,108 @@ eBPF-Tracing-Programme oder ähnliche Programme zu erstellen. Wenn Sie die Heade
 als Modul erstellen, wird ein Modul namens kheaders.ko erstellt, das bei Bedarf
 geladen werden kann, um Zugriff auf die Header zu erhalten.
 
+\subsection{Kernel log buffer size (16 $\Rightarrow$ 64KB, 17 $\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)\\
+Range: [12 25]
+\subsection{CPU kernel log buffer size contribution (13 $\Rightarrow$ 8 KB, 17 $\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 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)\\
+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$}{->}}
+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 20 \% Auslastung verfolgen. Eine um 25 \% 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,
+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
+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.
+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 fügt Unterstützung für automatische NUMA-bewusste
+Speicher-/Task-Platzierung hinzu.
+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.
+
 
 \end{document}