Die Neuerungen von Linux 3.14

Trends & News | Kernel-Log

Der Netzwerkcode kann kleine Datenhäppchen jetzt bündeln und dicke Downloads drosseln. Neben einem weiteren Prozess-Scheduler bringt der neue Kernel eine Reihe von Performance-Optimierungen. Ferner unterstützt Linux jetzt eine dritte Xen-Betriebsart sowie einige kürzlich vorgestellte Grafikkerne.

Zehn Wochen nach der Veröffentlichung von Linux 3.13 hat Linus Torvalds jetzt den Kernel 3.14 freigegeben. Dessen Radeon-Grafiktreiber unterstützt AMDs Dynamic Power Management (DPM) jetzt auch bei den neuesten Radeon-Grafikkernen vollständig und aktiviert die Stromspartechnik dort auch gleich automatisch (1, 2). Ferner kann der Treiber nun auch den Video-Decoder der Oland-GPUs nutzen, die auf den Radeon-HD-Modellen 8570 und 8670 stecken.

Der Intel-Grafiktreiber von 3.14 nutzt die zur Laufzeit verwendbaren Stromsparfunktionen von Grafikkernen stärker, die die Core-i-4000er-CPUs und andere Haswell-Prozessoren beherrschen (1, 2). Zudem ist die Unterstützung für den Grafikkern von Broadwell-CPUs jetzt standardmäßig aktiv; diesen Haswell-Nachfolger will Intel offenbar im Sommer einführen. Die Unterstützung für UMS (Userspace Mode Setting) in Intels Kernel-Treiber gilt ab Linux 3.14 als "deprecated" und soll im Verlauf der nächsten zwölf Monate nach und nach entfernt werden, wenn sich niemand beschwert. Betroffen sind davon nur Anwender mit sehr alten Linux-Distributionen, denn die DDX-Treiber für den X-Server beherrschen UMS schon seit ungefähr vier Jahren nicht mehr.

Der Nouveau-Treiber für Nvidia-GPUs bringt nun alles mit, um die 3D-Beschleunigung des GK208 zu verwenden – ein Grafikchip, der unter anderem auf den GeForce-GT-Modelle 630, 635 und 640 eingesetzt wird (1, 2). Neu in 3.14 ist auch die Unterstützung für den GK110 der GeForce GTX 780.

Zum Kernel stieß ferner ein Treiber für das Bochs Dispi Interface, das Qemu beim Aktivieren der VGA-Unterstützung standardmäßig emuliert. Einige weitere Änderungen an diesen und anderen Grafiktreibern listet der Haupt-Git-Pull-Request für den Direct Rendering Manager (DRM) des Kernels auf.

Der Prozess-Scheduler von 3.14 kann Teile der Prozessorzeit nach dem Schema Earliest Deadline First (EDF) verteilen (u. a. 1, 2, 3, 4, Dokumentation). Bei diesem vorwiegend für Echtzeit-Aufgaben interessanten Verfahren stellt der Kernel zuverlässig sicher, dass Anwendungen immer früh genug an die Reihe kommen, um ihre Arbeit fristgerecht zur gesetzten Deadline erledigen zu können. Dazu müssen die Tasks dem Scheduler aber auch mehr Informationen liefern als gewohnt: Aufruffrequenz, die maximale für die Aufgabe benötigte Laufzeit sowie den Zeitpunkt, bis zu dem die Aufgabe auf jeden Fall erledigt sein muss.

Bereitgestellt wird das Verteilverfahren durch die neue Deadline-Klasse im Completely Fair Scheduler (CFS) des Kernels. Sie darf maximal 95 Prozent der verfügbaren Rechenzeit in Anspruch nehmen, damit der CFS noch Prozessorzeit an reguläre Tasks verteilen kann. Obwohl die Entwicklung der Deadline-Scheduling-Patches über fünf Jahre in Anspruch genommen hat, stehen noch allerlei Dinge auf der To-do-Liste; darunter ein besseres Zusammenspiel mit der Realtime-Scheduling-Klasse des CFS und Erweiterungen, damit nicht nur privilegierte Anwender das neue Verfahren nutzen können.

Die neue Kernel Address Space Layout Randomization (KASLR) soll Angreifern das Leben erschweren (u. a. 1, 2, 3, 4). Durch die Technik legt der Kernel die Einsprungadressen seiner internen Funktionen bei jedem Start an andere Stellen des eigenen Speicherraums. Das macht es Übeltätern schwerer, beim Ausnutzen von Pufferüberläufen und ähnlichen Sicherheitslücken eine Kernel-Funktion zu finden, die ihnen höhere Rechte verschafft. Zuvor beherrschte der Kernel solches Adress-Zerhacken lediglich für Userspace-Software. Derzeit wird KASLR nur bei 32- und 64-Bit-x86-Prozessoren unterstützt; zudem lässt es sich bei der Kernel-Konfiguration nur aktivieren, wenn man die Unterstützung zum Suspend-to-Disk (Hibernate/Ruhezustand) deaktiviert.

Ceph unterstützt nun erweiterte Attribute. Zahlreiche Eigenschaften von Btrfs-Laufwerken lassen sich jetzt auch via Sysfs abfragen oder, sofern möglich, setzen; darunter die Dateisystembelegung oder die Features, die das Btrfs des jeweiligen Kernels beherrscht (1, 2). Ferner kann das weiterhin experimentelle Btrfs nun Dateisystem-spezifische Dateieigenschaften direkt als Extended Attribute (EA/Xattr) in der Inode speichern; etwa die Information, ob Btrfs eine Datei oder alle Dateien eines Verzeichnisses komprimieren soll. Zudem gab es einige Performance-Optimierungen an Btrfs.

Forum zum Thema

Kommentare

Anzeige