News Linux Kernel 2.6.38 erster Release Candidate

Onkel_Dithmeyer · 19.01.2011

<div class="newsfloatleft"><img src="http://www.planet3dnow.de/photoplog/images/50626/1_Linux-logo_80.gif" border="0" alt="Linux-Logo"></div>Linus Torvalds hat heute einen ersten Release Candidate (Vorabversion) des Kernel 2.6.38 freigegeben. Von den einigen tausend Änderungen stechen einige hervor. So soll der Kernel bei großer Auslastung kleine Threads besser verwalten. Als Resultat soll die Haptik der Oberfläche bei starker CPU-Last besser sein, da die Latenzen sinken.

Weiter soll die Geschwindigkeit erhöht werden, wenn mehrere Anwendungen gleichzeitig viele Dateipfade nutzen. Hierfür wurden kernelinterne Sperren durch RCUs (<a href="http://en.wikipedia.org/wiki/Read-copy-update" target="b">Read-copy-update</a>) ersetzt. Die Sperren sowie RCU schützen Bereiche und sorgen für eine Synchronisation, wenn mehrere Prozesse gleichzeitig auf diese Bereiche zugreifen und sie ändern wollen. Im Gegensatz zu den Sperren blockiert RCU dabei keine Prozesse, sondern lässt einen parallelen Zugriff auf den geschützten Bereich zu.

Außerdem fließt in den Kernel die Unterstützung für aktuelle Grafikchips von AMD, Nvidia und Intel. Für die AMD Chips werden dabei die 2D und 3D-Ausgabe für die Radeon 6200 bis 6800 unterstützt. Dazu zählt auch AMDs Fusion, nicht aber die 6900 (Cayman). Bei Nvidias Fermi unterstützt man nur test- und teilweise die Grafik. Hier empfiehlt es sich auf jeden Fall, die offiziellen Treiber zu verwenden. Für Intels Grafikeinheiten der Core ix hat man ein besseres Energiemanagement implementiert.

Es wurden auch noch weitere Treiber wie etwa Treiber wie etwa für den WLan-Chip RTL8192CE von Realtek wurde eingebunden. Für weitere Änderungen sei auf den umfangreichen <a href="http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.38-rc1" arget="b">Changelog</a> hingewiesen. Wer den Kernel ausprobieren will kann ihn sich auf <a href="http://kernel.org/" target="b">kernel.org</a> herunterladen.<p style="clear:left;">
<b>Quellen:</b>
<ul><li><a href="http://www.pro-linux.de/news/1/16605/linux-kernel-2638-tritt-in-die-testphase-ein.html" target="b">pro-linux.de</a></li><li><a href="http://www.heise.de/newsticker/meldung/Hauptentwicklungsphase-des-Linux-Kernel-2-6-38-abgeschlossen-1170916.html" target="b">Heise.de</a></li><li><a href="http://en.wikipedia.org/wiki/Read-copy-update" target="b">Wikipedia.org</a></li><li><a href="http://kernel.org/" target="b">kernel.org</a></li><li><a href="https://lkml.org/lkml/2011/1/18/322" target="b">lkml.org</a></li></ul>
<b>Links zum Thema:</b>
<ul><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=325066">Linux Linksammlung</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=324811">Linux Distributionen - Übersicht</a></li><li><a href="http://www.phoronix.com/scan.php?page=article&item=amd_driver_q111&num=1" target="b">Review: AMD Catalyst, Mesa & Gallium3D Drivers</a></li></ul></p>

Rausi · 20.01.2011

Wow - die Überschrift musste ich 2x lesen ...

Linx Kernel 2.6.38 erster Releas Candidate

Linux ... nicht Linx ... so ein Programm gibt es nämlich auch.
Und dann auch noch Release ohne e

[P3D] Crazy_Chris · 20.01.2011

Kernelnews hier auf P3dnow? Ist ja ganz was neues.

Beerman · 20.01.2011

[P3D] Crazy_Chris;4363717 schrieb:
Kernelnews hier auf P3dnow? Ist ja ganz was neues.

Eine positive Entwicklung, würde ich sagen... *great*

PuckPoltergeist · 20.01.2011

Onkel_Dithmeyer schrieb:
Von den einigen tausend Änderungen stechen einige hervor. So soll der Kernel bei großer Auslastung kleine Threads besser verwalten. Als Resultat soll die Haptik der Oberfläche bei starker CPU-Last besser sein, da die Latenzen sinken.

Das ist so nicht ganz richtig. Das Resultat stimmt zwar, aber das hat nichts mit großen oder kleinen Threads zu tun. Die Änderung führt eine automatische Erstellung von Taskgruppen ein, die vom Scheduler getrennt betrachtet werden. Dadurch können viele CPU-intensive Tasks in einer Gruppe nicht mehr den Rest so massiv wie früher beeinflussen.

Weiter soll die Geschwindigkeit von Anwendungen erhöht werden, die viele Dateipfade nutzen. Hierfür wurden kernelinterne Sperren durch RCUs (<a href="http://en.wikipedia.org/wiki/Read-copy-update" target="b">Read-copy-update</a>) ersetzt. Die Sperren sollen einen Overhead verhindern, die RCUs lassen hingegen einen gewissen Overhead zu.

Auch das stimmt so nicht. Einzelnen Anwendungen, die massiv Gebrauch von lookups machen, bringt die Änderung gar nichts. Die Lock-freie Implementierung des path name lookups beschleunigt parallele Zugriffe darauf, also wenn viele Anwendungen massiv Gebrauch davon machen. Das hat aber nichts mit einem Overhead zu tun, sondern damit, dass Locks prinzipiell den gleichzeitigen (schreibenden) Zugriff auf die gesperrten Sektionen verhindern, die entsprechenden Anwendungen also blockieren, während RCUs den Zugriff (mit entsprechendem Overhead) erlauben.

Nero24 · 20.01.2011

[P3D] Crazy_Chris;4363717 schrieb:
Kernelnews hier auf P3dnow? Ist ja ganz was neues.

Na, so neu und selten nun auch wieder nicht

[P3D] Crazy_Chris · 20.01.2011

Aber die letzte News ist von 2007. Und dabei kann ich mich ja nichtmal richtig erinnern was vorgestern war.

Onkel_Dithmeyer · 20.01.2011

Das mit der Überschrift ist mir furchtbar peinlich. :-[

Kommt hoffentlich nicht mehr vor...

PuckPoltergeist schrieb:
Das ist so nicht ganz richtig. Das Resultat stimmt zwar, aber das hat nichts mit großen oder kleinen Threads zu tun. Die Änderung führt eine automatische Erstellung von Taskgruppen ein, die vom Scheduler getrennt betrachtet werden. Dadurch können viele CPU-intensive Tasks in einer Gruppe nicht mehr den Rest so massiv wie früher beeinflussen.

Wenn ich das richtig verstehe werden die Threads nicht einzeln an den Scheduler gegeben, sondern gruppiert. Aber wieso wirkt sich das positiv aus?

PuckPoltergeist schrieb:
Auch das stimmt so nicht. Einzelnen Anwendungen, die massiv Gebrauch von lookups machen, bringt die Änderung gar nichts. Die Lock-freie Implementierung des path name lookups beschleunigt parallele Zugriffe darauf, also wenn viele Anwendungen massiv Gebrauch davon machen. Das hat aber nichts mit einem Overhead zu tun, sondern damit, dass Locks prinzipiell den gleichzeitigen (schreibenden) Zugriff auf die gesperrten Sektionen verhindern, die entsprechenden Anwendungen also blockieren, während RCUs den Zugriff (mit entsprechendem Overhead) erlauben.

Ok, ok, was die Locks bewirken ist mir klar, aber warum nutzt man die dann? Ich hätte jetzt gedacht, dass eine Lock-freie-Implementierung einen Overhead provozieren könnte.

PuckPoltergeist · 20.01.2011

Onkel_Dithmeyer schrieb:
Wenn ich das richtig verstehe werden die Threads nicht einzeln an den Scheduler gegeben, sondern gruppiert. Aber wieso wirkt sich das positiv aus?

Ein vereinfachtes Beispiel: Du startest unter X in einem Consolen-Programm ein parallelen Compile-Vorgang, z.b. mit 'make -j20'. Das startet 20 Compile-Prozesse gleichzeitig. Die wollen dann auch alle gleichzeitig Rechenzeit haben. Sehr vereinfacht hast du 20 Compile-Prozesse + 1 X-Prozess, die gleichzeitig um die CPU konkurrieren. Wenn jetzt alle Prozesse gleichberechtigt behandelt werden, werden sie reihum bedient, und der X-Prozess kommt immer erst dann wieder dran, wenn die 20 Compile-Prozesse gelaufen sind. Fasst man jetzt die 20 Compile-Prozesse aber in einer Task-Group zusammen und packt den X-Prozess in eine weitere Task-Group und schedult danach, bekommt der X-Prozess natürlich viel häufiger Laufzeit zugewiesen. Damit steigt dann die Reaktivität der GUI.
Die Task Groups sind auch nicht neu. Neu ist jetzt, dass diese jetzt automatisch erstellt werden. Das konnte man früher auch schon selber so machen, wenn man wollte. Müsste nachschauen, wann die im Kernel eingeführt wurden.

Ok, ok, was die Locks bewirken ist mir klar, aber warum nutzt man die dann? Ich hätte jetzt gedacht, dass eine Lock-freie-Implementierung einen Overhead provozieren könnte.

Erstmal, was verstehst du unter Overhead?

Die Locks sind eine Form der Serialisierung. Sie werden beim Zugriff auf kritische Sektionen genutzt. Immer, wenn mehrere Akteure zur gleichen Zeit auf ein Objekt zugreifen wollen, welches den Zugriff nur nacheinander erlaubt, muss das serialisiert werden. Um mal ein ganz triviales Beispiel aus der realen Welt zu nehmen, es kann immer nur einer zur gleichen Zeit aufs Klo gehen. Sitzt da schon einer und jemand anderes will auch, muss er zwangsläufig warten. Das Lock dafür wäre dann der Schlüssel an der Klotür.
Um jetzt zum Kernel zurück zu kommen, die einfachste Variante zur Serialisierung ist ein Lock, welches den betreffenden Bereich sperrt. Betritt ein Prozess diesen Bereich, fordert er das Lock an, macht seine Arbeit und gibt das Lock beim Verlassen des Bereichs wieder frei. Jeder andere Prozess, der in der Zwischenzeit das Lock anfordert, wird so lange aufgehalten. Das skaliert nun nicht besonders gut mit der Anzahl der Prozesse, die gleichzeitig in diesen Bereich wollen. Deshalb gibt es verschiedene Techniken, die dieses Problem etwas entschärfen. RCUs als lockless Technik ist eine davon. Sie erlaubt das parallele abarbeiten des geschützten Bereichs durch mehrere Prozesse, im Gegensatz zu einem Lock. Wenn aber mehrere Prozesse gleichzeitig einen geschützten Bereich betreten können, muss das bei Änderungen in diesem Bereich während der Abarbeitung berücksichtigt werden. Sonst gibt es Inkonsistenzen. Und hier entsteht der Overhead bei RCU im Gegensatz zu Locks. Bei einem Lock entsteht keine zusätzliche Arbeit, wenn der Prozess, der den geschützten Bereich betreten hat, diesen verändert.

PS: Vor allem, die Formulierung:

Weiter soll die Geschwindigkeit von Anwendungen erhöht werden, die viele Dateipfade nutzen. Hierfür wurden kernelinterne Sperren durch RCUs (Read-copy-update) ersetzt. Die Sperren sollen einen Overhead verhindern, die RCUs lassen hingegen einen gewissen Overhead zu.

ist ziemlich schlecht. Da steht, die neue Implementierung ist schneller, weil sie mehr Overhead erzeugt. Oder anders gesagt, die neue Implementierung ist schneller, weil sie langsamer ist. Das sollte auf jeden Fall nochmal überarbeitet werden.

SnakePlisken · 20.01.2011

Sind die RCUs in Verbindung mit der deaktivierung von BKL zu sehen. Wie müsste man das denn konfigurieren? Komplette RCU subsytem rein?

PuckPoltergeist · 20.01.2011

SnakePlisken schrieb:
Sind die RCUs in Verbindung mit der deaktivierung von BKL zu sehen.

Nope, RCU existiert schon sehr lange im Kernel. Das wird zwar auch als Ersatz für das BKL mit eingesetzt, ist aber nicht direkt im Zusammenhang mit der gerade stattfindenden Entfernung des BKL zu sehen.

Wie müsste man das denn konfigurieren? Komplette RCU subsytem rein?

Solltest du gar nicht anfassen. Siehe oben, RCU wird schon lange genutzt. Das kannst du gar nicht abschalten. Und das BKL solltest du auch in Ruhe lassen, sofern du nicht genau weißt, was du tust. Die Option, das zu deaktivieren, ist für Entwickler gedacht, die an der Entfernung arbeiten.

SnakePlisken · 20.01.2011

OK, hatte nur gelesen, dass nicht mehr ganz so viele ältere Treiber den BKL noch brauchen. Die Möglichkeit zur Deaktivierung wurde ja groß angekündigt. Hätts aber eh vorerst nicht gemacht.

PuckPoltergeist · 20.01.2011

SnakePlisken schrieb:
OK, hatte nur gelesen, dass nicht mehr ganz so viele ältere Treiber den BKL noch brauchen. Die Möglichkeit zur Deaktivierung wurde ja groß angekündigt. Hätts aber eh vorerst nicht gemacht.

So lange du keinen Treiber brauchst, der das BKL noch nutzt, ist das für dich als Anwender eh egal. Dann kommst du auch nicht damit in Berührung, egal ob der Kernel das noch enthält oder nicht.

Überhaupt wird der Hype um die Entfernung des BKL ziemlich überbewertet.

Ragas · 20.01.2011

Onkel_Dithmeyer schrieb:
<div class="newsfloatleft"><img src="http://www.planet3dnow.de/photoplog/images/50626/1_Linux-logo_80.gif" border="0" alt="Linux-Logo"></div>Linus Torvalds hat heute einen ersten Release Candidate (Vorabversion) des Kernel 2.6.38 freigegeben. Von den einigen tausend Änderungen stechen einige hervor. So soll der Kernel bei großer Auslastung kleine Threads besser verwalten. Als Resultat soll die Haptik der Oberfläche bei starker CPU-Last besser sein, da die Latenzen sinken.

Also zuerst will ich mal gerne wissen, was denn bitte ein "kleiner" Thread ist?! *buck*

Und dann wäre es vielleicht nicht schlecht zu erwähnen, dass diese Änderung nur Einfluss auf rechenintensive Prozesse in Terminals hat.
Also sowas wie ein make -j5 kann nicht mehr den Videoplayer in die Knie zwingen.

Aber ich begrüße es sehr hier mehr Linux, Kernel News zu lesen.
.
EDIT :
.

SnakePlisken schrieb:
OK, hatte nur gelesen, dass nicht mehr ganz so viele ältere Treiber den BKL noch brauchen. Die Möglichkeit zur Deaktivierung wurde ja groß angekündigt. Hätts aber eh vorerst nicht gemacht.

Derzeit brauchen nurnoch sehr alte Treiber und das Video4Linux Framework den BKL.
Wenn ich nicht V4L benutzen würde hätte ich den BKL auch schonmal probeweise deaktiviert.

Dr@ · 20.01.2011

Ist nur die Frage, ob sich noch mal jemand traut eine News zum Thema Linux zu verfassen. ...

PuckPoltergeist · 20.01.2011

Ragas schrieb:
Also zuerst will ich mal gerne wissen, was denn bitte ein "kleiner" Thread ist?!

Und dann wäre es vielleicht nicht schlecht zu erwähnen, dass diese Änderung nur Einfluss auf rechenintensive Prozesse in Terminals hat.
Also sowas wie ein make -j5 kann nicht mehr den Videoplayer in die Knie zwingen.

Betrifft nicht nur Prozesse in Terminals. Rechenmonster kannst du auch anders zusammenstellen. Das mit den Terminals ist nur ein Beispiel. Aus einer IDE wie Eclipse oder KDevelop dürftest du das auch hinbekommen.

Ok, Korrektur, du hast Recht. Das betrifft standardmäßig wirklich nur Terminals, da IDEs per default keine neuen task sessions aufmachen.

Ragas · 20.01.2011

Dr@ schrieb:
Ist nur die Frage, ob sich noch mal jemand traut eine News zum Thema Linux zu verfassen. ...

Warum denn nicht? kann doch mal passieren, dass etwas nicht ganz korrekt ist. Und gerade auf einer Seite wo man von Linux nicht ganz so viel hört ist das eigentlich in Ordnung wenn ein par Fehler drin sind.

Natürlich kommen dann aber die Besserwisser und korrigieren.

Dr@ · 20.01.2011

Ragas schrieb:
Warum denn nicht? kann doch mal passieren, dass etwas nicht ganz korrekt ist. Und gerade auf einer Seite wo man von Linux nicht ganz so viel hört ist das eigentlich in Ordnung wenn ein par Fehler drin sind.

Natürlich kommen dann aber die Besserwisser und korrigieren.

Noch viel toller wäre es natürlich, wenn sich ein Linux-Experte finden würde, der hier regelmäßig News rund um Linux postet.

Dann würde man gleich viel mehr hören.

Ragas · 20.01.2011

PuckPoltergeist schrieb:
Betrifft nicht nur Prozesse in Terminals. Rechenmonster kannst du auch anders zusammenstellen. Das mit den Terminals ist nur ein Beispiel. Aus einer IDE wie Eclipse oder KDevelop dürftest du das auch hinbekommen.

Die CGroups kann man auch für andere Sachen einsetzen, das stimmt.

Aber der Patch der das jetzt im Kernel automatisch vornimmt funktioniert nur für Terminals und erzeugt für jedes Terminal eine eigene cgroup.
Den selben Effekt wie dieser Patch kann man übrigens auch mit einem einfachen Skript in der .bashrc erreichen.

Gerade weil der Kernel eigentlich nicht besonders gute Möglichkeiten hat um herauszufinden wie Prozesse optimal gruppiert werden können, ist der Patch auch stark umstritten.
Die Diskussion dazu zwischen Linus und dem Systemd Hauptentwickler ist auch recht interessant.

Systemd ist gerade daran eine ähnliche Funktionalität zu implementieren und könnte potentiell noch bessere Ergebnisse erzielen.
Zudem ist aus dieser Diskussion noch ein weiteres Projekt entstanden welches CGroups steuern will.

PuckPoltergeist · 20.01.2011

Ragas schrieb:
Die CGroups kann man auch für andere Sachen einsetzen, das stimmt.

Aber der Patch der das jetzt im Kernel automatisch vornimmt funktioniert nur für Terminals und erzeugt für jedes Terminal eine eigene cgroup.
Den selben Effekt wie dieser Patch kann man übrigens auch mit einem einfachen Skript in der .bashrc erreichen.

Nur für Terminals stimmt nicht. Er gruppiert automatisch nach task session und das betrifft wohl standardmäßig nur die Terminals. Würde eine IDE eine neue task session aufmachen, würde sie aber ebenso gruppiert werden. Nur macht das standardmäßig kaum eine Software.

Ragas · 20.01.2011

PuckPoltergeist schrieb:
Nur für Terminals stimmt nicht. Er gruppiert automatisch nach task session und das betrifft wohl standardmäßig nur die Terminals. Würde eine IDE eine neue task session aufmachen, würde sie aber ebenso gruppiert werden. Nur macht das standardmäßig kaum eine Software.

Ok damit hast du wohl recht.

Ich schlage Puck. Als Linux Moderator vor

PuckPoltergeist · 21.01.2011

Ragas schrieb:
Derzeit brauchen nurnoch sehr alte Treiber und das Video4Linux Framework den BKL.
Wenn ich nicht V4L benutzen würde hätte ich den BKL auch schonmal probeweise deaktiviert.

V4L nutzt das BKL auch nicht mehr. Und wenn ich jetzt nicht irre, sind die Patches dafür schon in 2.6.37 eingeflossen. Beschwören will ich das jetzt aber nicht. Aber wie gesagt, der Hype, der gerade darum gemacht wird, ist eh deplatziert.

PuckPoltergeist · 24.01.2011

Gerade mal eine halbe Woche nach Release Candidate 1 hat Linus Thorvalds jetzt rc2 freigegeben. Dieser ungewöhnlich frühe Termin hängt maßgeblich mit der linux.conf.au zusammen, welche gerade (24.1.-29.1.) in Brisbane stattfindet, und bei der Linus anwesend ist.
Aber auch trotz der frühen Freigabe von rc2 sind wieder viele Updates eingeflossen. Hauptsächlich betroffen waren diesmal das Media Subsystem (v4l/dvb) und das cifs (Common Internet File System, der Nachfolger vom smbfs).

News Linux Kernel 2.6.38 erster Release Candidate

Redaktion☆☆☆☆☆☆

Cadet

Grand Admiral Special

Commodore Special

Grand Admiral Special

Administrator

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Vice Admiral Special

Grand Admiral Special

Vice Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Ähnliche Themen

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆