Linux Kernel Architecture: Core Components (Artikel 361)
Tiefgehende Analyse der Linux-Kernel-Architektur. Erfahren Sie alles über das monolithische Design, die Trennung von User- und Kernel-Space sowie die wichtigsten Subsysteme des Betriebssystems.
# Linux Kernel Architecture: Das Herz des Systems verstehen
TL;DR / Management Summary Der Linux-Kernel ist der Vermittler zwischen Hardware und Software. In diesem Modul tauchen wir tief in sein monolithisches Design ein. Wir verstehen, warum Linux trotz seiner Größe extrem performant ist, wie der System-Call-Layer den User-Space (Ring 3) vom privilegierten Kernel-Space (Ring 0) trennt und welche Aufgaben die Kern-Subsysteme wie der Scheduler und das VFS (Virtual File System) übernehmen. Wer den Kernel versteht, kann Performance-Probleme an der Wurzel packen.
# 1. Einführung: Das monolithische Design
Alles in einem Boot.
Im Gegensatz zu Microkernels (wie bei macOS oder Windows NT teilweise) führt Linux fast alle seine Aufgaben (Treiber, Dateisysteme, Netzwerk) im privilegierten Modus aus.
- Vorteil: Minimale Latenz, da keine Kommunikation zwischen isolierten Diensten nötig ist.
- Nachteil: Ein Fehler in einem Treiber kann das gesamte System zum Absturz bringen (Kernel Panic).
# 2. User-Space vs. Kernel-Space
Die Ring-Architektur.
Moderne CPUs (x86_64) nutzen Schutzringe, um das System abzusichern.
- Ring 0 (Kernel Space): Voller Zugriff auf die Hardware. Hier lebt der Linux-Kernel.
- Ring 3 (User Space): Hier laufen Ihre Applikationen (Bash, Nginx, Python). Jede Hardware-Anfrage muss über einen System Call (syscall) an Ring 0 gestellt werden.
# Die Architektur-Schichten (Mermaid)
graph TD
A[User Space: App / Process] -->|1. System Call| B[Kernel Interface: syscalls]
subgraph "Linux Kernel (Ring 0)"
B --> C[Process Management: Scheduler]
B --> D[Memory Management: Virtual Memory]
B --> E[Filesystem: VFS / Ext4]
B --> F[Network Stack: TCP/IP]
B --> G[Device Drivers: Disk, Net, GPU]
end
G --> H[Physical Hardware: CPU / RAM / I/O]
# 3. Die Kern-Subsysteme
Die Organe des Kernels.
# 1. Process Management (The Scheduler)
Der Scheduler entscheidet, welcher Prozess wann auf welchem CPU-Kern rechnen darf. Linux nutzt heute den CFS (Completely Fair Scheduler).
# 2. Memory Management (MMU)
Verwaltet den virtuellen Speicher. Er sorgt dafür, dass jeder Prozess denkt, er habe den gesamten RAM für sich allein, und schützt Speicherbereiche vor unbefugtem Zugriff.
# 3. VFS (Virtual File System)
Die Abstraktionsschicht für Speicher. Sie sorgt dafür, dass ein ls Befehl auf einer SSD, einem NFS-Share oder einer RAM-Disk identisch funktioniert.
# 4. Day-2 Operations: Kernel-Versionen lesen
Was bedeuten die Nummern?
Beispiel: 6.5.0-27-generic
- 6: Major Version (Große architektonische Änderungen).
- 5: Minor Version (Neue Features, Treiber).
- 0: Patch Level (Bugfixes).
- 27: Distro-spezifischer Build.
# 5. Troubleshooting & “War Stories”
Wenn der Kernel panisch wird.
# Story 1: “Der hängende Syscall”
Symptom: Ein Prozess lässt sich nicht mit kill -9 beenden. Der Status ist D (Uninterruptible Sleep).
Ursache: Der Prozess wartet im Kernel-Space auf eine Antwort der Hardware (oft ein hängender NFS-Mount oder eine defekte HDD). Da der Prozess gerade “im” Kernel ist, ignoriert er alle Signale aus dem User-Space.
Lösung: Beheben Sie das Hardware-Problem oder starten Sie den Server neu.
# Story 2: “Das System-Call Overhead”
Symptom: Eine High-Performance Applikation (z.B. ein Proxy) erreicht nicht den vollen Durchsatz, obwohl die CPU-Last niedrig ist.
Ursache: Zu viele Kontext-Wechsel zwischen User- und Kernel-Space. Jedes Mal, wenn die App read() oder write() ruft, muss die CPU den Modus wechseln.
Lösung: Nutzen Sie moderne Techniken wie io_uring oder eBPF, um Operationen direkt im Kernel zu verarbeiten und Kontext-Wechsel zu minimieren.
# 6. Fazit & Empfehlung
- Verständnis: Betrachten Sie den Kernel als den einzigen Prozess, der die Wahrheit über die Hardware kennt.
- Wartung: Halten Sie Ihren Kernel aktuell (Artikel 344), um von Verbesserungen im Scheduler und Netzwerk-Stack zu profitieren.
- Wahl: Nutzen Sie für Virtualisierung immer den Generic Kernel. Spezialisierte Kerne (RT, Low-Latency) sind nur für Echtzeit-Aufgaben sinnvoll.
# Anhang: Cheatsheet für Kernel-Checker
| Aufgabe | Befehl |
|---|---|
| Kernel Version | uname -a |
| Geladene Module | lsmod |
| Kernel Meldungen | dmesg -T |
| Syscall-Audit | strace -p <pid> |
| Kernel Parameter | sysctl -a |
| CPU-Features | lscpu |
| Memory Details | cat /proc/meminfo |
| PCI-Geräte | lspci -v |