App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
News Linux Kernel 2.6.38 erster Release Candidate
- Ersteller Onkel_Dithmeyer
- Erstellt am
Onkel_Dithmeyer
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 22.04.2008
- Beiträge
- 12.950
- Renomée
- 4.023
- Standort
- Zlavti
- Aktuelle Projekte
- Universe@home
- Lieblingsprojekt
- Universe@home
- Meine Systeme
- cd0726792825f6f563c8fc4afd8a10b9
- BOINC-Statistiken
- Prozessor
- Ryzen 9 3900X @4000 MHz//1,15V
- Mainboard
- MSI X370 XPOWER GAMING TITANIUM
- Kühlung
- Custom Wasserkühlung vom So. G34
- Speicher
- 4x8 GB @ 3000 MHz
- Grafikprozessor
- Radeon R9 Nano
- Display
- HP ZR30W & HP LP3065
- SSD
- 2 TB ADATA
- Optisches Laufwerk
- LG
- Soundkarte
- Im Headset
- Gehäuse
- Xigmatek
- Netzteil
- BeQuiet Dark Pro 9
- Tastatur
- GSkill KM570
- Maus
- GSkill MX780
- Betriebssystem
- Ubuntu 20.04
- Webbrowser
- Firefox Version 94715469
- Internetanbindung
- ▼100 Mbit ▲5 Mbit
<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>
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>
Zuletzt bearbeitet:
Rausi
Cadet
- Mitglied seit
- 13.02.2009
- Beiträge
- 9
- Renomée
- 0
- Standort
- Chemnitz
- Prozessor
- Phenom II X4 965 BE
- Mainboard
- Gigabyte GA-MA790FXT-UD5P
- Kühlung
- WaKü cuplex XT di²
- Speicher
- 4x 4GByte DDR3-1333 GEiL
- Grafikprozessor
- Sapphire Radeon 7850 2 GByte
- Display
- Chimei CMV 222H
- HDD
- mehrere verschiedene
- Optisches Laufwerk
- LG DVD-Brenner
- Soundkarte
- onboard (ALC889a)
- Gehäuse
- Lian Li PC-A70B
- Netzteil
- Enermax MODU82+ 525 Watt
- Betriebssystem
- OpenSUSE 11.4
- Webbrowser
- Firefox
- Verschiedenes
- WaKü Pumpe+AG+3fach-Radi von Aqua-Computer
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
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
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.451
- Renomée
- 116
- Mein Laptop
- Sony Vaio VPC-CW2S1E/R (14,1", Core i3 330M, GeForce GT 330M, Intel X25-M G2 80 GB)
- Prozessor
- Intel Core i5-750 @ 3.36Ghz (1,18V)
- Mainboard
- Gigabyte GA-P55M-UD2
- Kühlung
- Scythe Mugen 2 Rev. B
- Speicher
- 4x 2GB G.Skill F3-12800CL9D-4GBNQ (DDR3-1600)
- Grafikprozessor
- Gigabyte GV-N570OC-13I (GeForce GTX 570 OC 1280MB GDDR5)
- Display
- Dell UltraSharp 2407WFP
- HDD
- Crucial RealSSD C300 128 GB, Samsung SpinPoint F3 1TB
- Optisches Laufwerk
- LG GGC-H20L SATA *Blu-ray*
- Soundkarte
- Creative Sound Blaster X-Fi Titanium PCIe
- Gehäuse
- Silverstone Temjin TJ08 µATX
- Netzteil
- ELVT NesteQ NA4501 (450 W, Semipassiv)
- Betriebssystem
- Windows 7 und Ubuntu (x64)
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- guckguck :-P
Kernelnews hier auf P3dnow? Ist ja ganz was neues.
Beerman
Commodore Special
- Mitglied seit
- 23.09.2003
- Beiträge
- 470
- Renomée
- 7
[P3D] Crazy_Chris;4363717 schrieb:Kernelnews hier auf P3dnow? Ist ja ganz was neues.
Eine positive Entwicklung, würde ich sagen...
PuckPoltergeist
Grand Admiral Special
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.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.
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.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.
Na, so neu und selten nun auch wieder nicht[P3D] Crazy_Chris;4363717 schrieb:Kernelnews hier auf P3dnow? Ist ja ganz was neues.
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1192018274
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1183975445
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1170698405
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1164926680
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1158741734
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1136311762
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1131712279
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1131642044
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1119264725
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1113288163
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1109769793
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1098204321
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1092488524
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1091964291
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1087374879
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1084213124
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1082062895
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1079074802
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1077130738
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1075883454
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1074620634
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1073721738
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1073314839
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1071753146
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1070483021
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1070115634
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1038566229
[P3D] Crazy_Chris
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.451
- Renomée
- 116
- Mein Laptop
- Sony Vaio VPC-CW2S1E/R (14,1", Core i3 330M, GeForce GT 330M, Intel X25-M G2 80 GB)
- Prozessor
- Intel Core i5-750 @ 3.36Ghz (1,18V)
- Mainboard
- Gigabyte GA-P55M-UD2
- Kühlung
- Scythe Mugen 2 Rev. B
- Speicher
- 4x 2GB G.Skill F3-12800CL9D-4GBNQ (DDR3-1600)
- Grafikprozessor
- Gigabyte GV-N570OC-13I (GeForce GTX 570 OC 1280MB GDDR5)
- Display
- Dell UltraSharp 2407WFP
- HDD
- Crucial RealSSD C300 128 GB, Samsung SpinPoint F3 1TB
- Optisches Laufwerk
- LG GGC-H20L SATA *Blu-ray*
- Soundkarte
- Creative Sound Blaster X-Fi Titanium PCIe
- Gehäuse
- Silverstone Temjin TJ08 µATX
- Netzteil
- ELVT NesteQ NA4501 (450 W, Semipassiv)
- Betriebssystem
- Windows 7 und Ubuntu (x64)
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- guckguck :-P
Aber die letzte News ist von 2007. Und dabei kann ich mich ja nichtmal richtig erinnern was vorgestern war.
Onkel_Dithmeyer
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 22.04.2008
- Beiträge
- 12.950
- Renomée
- 4.023
- Standort
- Zlavti
- Aktuelle Projekte
- Universe@home
- Lieblingsprojekt
- Universe@home
- Meine Systeme
- cd0726792825f6f563c8fc4afd8a10b9
- BOINC-Statistiken
- Prozessor
- Ryzen 9 3900X @4000 MHz//1,15V
- Mainboard
- MSI X370 XPOWER GAMING TITANIUM
- Kühlung
- Custom Wasserkühlung vom So. G34
- Speicher
- 4x8 GB @ 3000 MHz
- Grafikprozessor
- Radeon R9 Nano
- Display
- HP ZR30W & HP LP3065
- SSD
- 2 TB ADATA
- Optisches Laufwerk
- LG
- Soundkarte
- Im Headset
- Gehäuse
- Xigmatek
- Netzteil
- BeQuiet Dark Pro 9
- Tastatur
- GSkill KM570
- Maus
- GSkill MX780
- Betriebssystem
- Ubuntu 20.04
- Webbrowser
- Firefox Version 94715469
- Internetanbindung
- ▼100 Mbit ▲5 Mbit
Das mit der Überschrift ist mir furchtbar peinlich. Kommt hoffentlich nicht mehr vor...
Wenn ich das richtig verstehe werden die Threads nicht einzeln an den Scheduler gegeben, sondern gruppiert. Aber wieso wirkt sich das positiv aus?
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.
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?
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
Grand Admiral Special
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.Wenn ich das richtig verstehe werden die Threads nicht einzeln an den Scheduler gegeben, sondern gruppiert. Aber wieso wirkt sich das positiv aus?
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.
Erstmal, was verstehst du unter Overhead?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.
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:
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.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.
Zuletzt bearbeitet:
SnakePlisken
Vice Admiral Special
Sind die RCUs in Verbindung mit der deaktivierung von BKL zu sehen. Wie müsste man das denn konfigurieren? Komplette RCU subsytem rein?
PuckPoltergeist
Grand Admiral Special
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.Sind die RCUs in Verbindung mit der deaktivierung von BKL zu sehen.
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.Wie müsste man das denn konfigurieren? Komplette RCU subsytem rein?
SnakePlisken
Vice Admiral Special
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
Grand Admiral Special
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.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.
Überhaupt wird der Hype um die Entfernung des BKL ziemlich überbewertet.
Zuletzt bearbeitet:
Ragas
Grand Admiral Special
- Mitglied seit
- 24.05.2005
- Beiträge
- 4.470
- Renomée
- 85
- Prozessor
- AMD Athlon 64 X2 3800+ @2520MHz; 1,4V; 53°C
- Mainboard
- Asus A8N-E
- Kühlung
- Thermaltake Sonic Tower (doppelt belüftet)
- Speicher
- 4x Infineon DDR400 512MB @207MHz
- Grafikprozessor
- Nvidia GeForce FX 7800GT
- Display
- 1.: 24", Samsung SyncMaster 2443BW, 1920x1200 TFT 2.: 19", Schneider, 1280x1024 CRT
- HDD
- Seagate Sata1 200GB 7200rpm, 2x250GB Seagate SATA2 im Raid0
- Optisches Laufwerk
- DVDBrenner LG GSA 4167
- Soundkarte
- Creative X-Fi Extreme Music
- Gehäuse
- Thermaltake Soprano Silber
- Netzteil
- Be-quiet! Darkpower 470W
- Betriebssystem
- Windows XP; Linux Mandriva 2007.1 (Kernel: 2.6.22.2 Ragas-Edition :D )
- Webbrowser
- Firefox
- Verschiedenes
- -Lüftersteuerung: Aerogate3
<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?!
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 :
.
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@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
Ist nur die Frage, ob sich noch mal jemand traut eine News zum Thema Linux zu verfassen. ...
PuckPoltergeist
Grand Admiral Special
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.
Ok, Korrektur, du hast Recht. Das betrifft standardmäßig wirklich nur Terminals, da IDEs per default keine neuen task sessions aufmachen.
Zuletzt bearbeitet:
Ragas
Grand Admiral Special
- Mitglied seit
- 24.05.2005
- Beiträge
- 4.470
- Renomée
- 85
- Prozessor
- AMD Athlon 64 X2 3800+ @2520MHz; 1,4V; 53°C
- Mainboard
- Asus A8N-E
- Kühlung
- Thermaltake Sonic Tower (doppelt belüftet)
- Speicher
- 4x Infineon DDR400 512MB @207MHz
- Grafikprozessor
- Nvidia GeForce FX 7800GT
- Display
- 1.: 24", Samsung SyncMaster 2443BW, 1920x1200 TFT 2.: 19", Schneider, 1280x1024 CRT
- HDD
- Seagate Sata1 200GB 7200rpm, 2x250GB Seagate SATA2 im Raid0
- Optisches Laufwerk
- DVDBrenner LG GSA 4167
- Soundkarte
- Creative X-Fi Extreme Music
- Gehäuse
- Thermaltake Soprano Silber
- Netzteil
- Be-quiet! Darkpower 470W
- Betriebssystem
- Windows XP; Linux Mandriva 2007.1 (Kernel: 2.6.22.2 Ragas-Edition :D )
- Webbrowser
- Firefox
- Verschiedenes
- -Lüftersteuerung: Aerogate3
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@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
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
Grand Admiral Special
- Mitglied seit
- 24.05.2005
- Beiträge
- 4.470
- Renomée
- 85
- Prozessor
- AMD Athlon 64 X2 3800+ @2520MHz; 1,4V; 53°C
- Mainboard
- Asus A8N-E
- Kühlung
- Thermaltake Sonic Tower (doppelt belüftet)
- Speicher
- 4x Infineon DDR400 512MB @207MHz
- Grafikprozessor
- Nvidia GeForce FX 7800GT
- Display
- 1.: 24", Samsung SyncMaster 2443BW, 1920x1200 TFT 2.: 19", Schneider, 1280x1024 CRT
- HDD
- Seagate Sata1 200GB 7200rpm, 2x250GB Seagate SATA2 im Raid0
- Optisches Laufwerk
- DVDBrenner LG GSA 4167
- Soundkarte
- Creative X-Fi Extreme Music
- Gehäuse
- Thermaltake Soprano Silber
- Netzteil
- Be-quiet! Darkpower 470W
- Betriebssystem
- Windows XP; Linux Mandriva 2007.1 (Kernel: 2.6.22.2 Ragas-Edition :D )
- Webbrowser
- Firefox
- Verschiedenes
- -Lüftersteuerung: Aerogate3
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
Grand Admiral Special
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.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.
Ragas
Grand Admiral Special
- Mitglied seit
- 24.05.2005
- Beiträge
- 4.470
- Renomée
- 85
- Prozessor
- AMD Athlon 64 X2 3800+ @2520MHz; 1,4V; 53°C
- Mainboard
- Asus A8N-E
- Kühlung
- Thermaltake Sonic Tower (doppelt belüftet)
- Speicher
- 4x Infineon DDR400 512MB @207MHz
- Grafikprozessor
- Nvidia GeForce FX 7800GT
- Display
- 1.: 24", Samsung SyncMaster 2443BW, 1920x1200 TFT 2.: 19", Schneider, 1280x1024 CRT
- HDD
- Seagate Sata1 200GB 7200rpm, 2x250GB Seagate SATA2 im Raid0
- Optisches Laufwerk
- DVDBrenner LG GSA 4167
- Soundkarte
- Creative X-Fi Extreme Music
- Gehäuse
- Thermaltake Soprano Silber
- Netzteil
- Be-quiet! Darkpower 470W
- Betriebssystem
- Windows XP; Linux Mandriva 2007.1 (Kernel: 2.6.22.2 Ragas-Edition :D )
- Webbrowser
- Firefox
- Verschiedenes
- -Lüftersteuerung: Aerogate3
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
Grand Admiral Special
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.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.
PuckPoltergeist
Grand Admiral Special
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).
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).
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 2K
- Antworten
- 4
- Aufrufe
- 2K
- Antworten
- 0
- Aufrufe
- 1K