News Linux: Linus Torvalds zu den Chancen von Kdbus im Kernel

fethomm · 24. Juni 2015

Auf der Kernel-Mailingliste hat Linus Torvalds auf die Frage eines Kernel-Entwicklers geantwortet, ob er Kdbus generell in den Kernel aufnehmen würde. Torvalds ist demnach gewillt, Kdbus durchzuwinken, wenn die kritisierten Schwachstellen beseitigt sind und der Code erneut eingereicht wird.

Zur News: Linux: Linus Torvalds zu den Chancen von Kdbus im Kernel

CvH · 24. Juni 2015

Naja irgendwie so richtig einleuchtend ist die Begründung auch nicht, wenn keiner den Userspace verbessert bleibt für den Anwender immer noch die "tolle" Performance von Dbus übrig. Wenn für DBus sich halt niemand zuständig fühlt aber welche eine allgemein bessere alternative schaffen warum nicht ? Das man Dbus evtl zur selben Leistung antreiben könnte ist zwar nett aber wer und wie soll das passieren ?

TrueAzrael · 24. Juni 2015

Die Leute die kdbus bauen, könnten die selbe Zeit investieren um dbus zu optimieren. Nur weil man zu faul zum optimieren der Software ist, muss man die nun wirklich nicht im Kernel mit allen Privilegien laufen lassen. Aber ist ja nicht mein Bier, die werden sich schon abschlachten bis nur noch einer steht.

Faust2011 · 24. Juni 2015

Die sollen die aktuelle Implementierung (die im UserSpace läuft) einfach mal profilen und dementsprechend optimieren. Sagte Torvalds nicht bereits, dass man da einiges an Performance rausholen kann und dann gar nicht den Vorteil braucht, den die Runtime im KernelSpace mit sich bringt?

Piktogramm · 24. Juni 2015

Linus hat den Spaß bereits einem Profiling unterzogen und dazu gibt es in der entsprechenden Mailinglist eine entsprechende Aussage von ihm, mit gewohnt direkter Sprachwahl, die mittlerweile anscheinend noch direkter geworden ist (siehe die hier geschriebene News). Er hat entsprechend schon gefordert, dass da aufgeräumt werden muss!

sunnyday · 24. Juni 2015

Tja Programmierkot performed halt nicht gut.

Miuwa · 24. Juni 2015

Soweit ich die Diskussion verfolgen konnte, kommt das Problem zum Teil daher, dass ein Großteil des derzeit schlecht optimierten DBus Codes bei Kdbus ohnehin überflüssig werden würde, weshalb die Entwickler nur wenig Energie in diese Teile stecken wollen.

Ich verstehe die Positionen so:
- Kdbus Befürworter "Egal, wie sehr wir unseren Userspace Code optimieren, das Ergebnis wird prinzipbedingt deutlich langsamer als eine Kernelversion sein, also stecken wir unsere Energie gleich in Kdbus".
- Linus: "Beweist erstmal, dass eine optimierte Userspace Dbus-Version immer noch zu langsam für den gedachten Einsatzzweck ist. Vorher ist der Performacnegewinn [der glaube ich nicht abgestritten wird] bei Aufnahme in den Kernel kein Argument."

Piktogramm · 24. Juni 2015

Linus kleiner Beitrag zum Dbus Profiling
http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166

wayne_757 · 24. Juni 2015

Der Torvalds wird einfach auch immer mehr zum Suppenkasper.
Wenn er mal mit offenen Augen auf sein Projekt schauen würde dann würde er nicht so auf anderen herumhacken, weil die Kernkomponenten von Linux nämlich genauso vermurkst sind.
Statt sich von Unix zu emanzipieren, hat man von dort sämtliche Designschwächen übernommen.
Herausgekommen ist ein System dass aus Applikationssicht unheimlich schwer zu programmieren ist (im Sinne von 100% korrekt). Dazu gehören:

- Signal safe programming
- Signals in multithread applications
- fork+overcommit
- fork+exec+file descriptors

Aber klar, dass wird dann einfach mit einem "pure shit user space code" weggebügelt...ich krieg mich nicht mehr.

Faust2011 · 24. Juni 2015

wayne_757 schrieb:
- Signal safe programming
- Signals in multithread applications
- fork+overcommit
- fork+exec+file descriptors

Nicht jedes Programm besteht primär aus Nebenläufigkeit und Ressourcen-Sharing, auch wenn man natürlich mit der Kernel-API nur dann in Berührung kommt, wenn man in die Systemprogrammierung abgleitet (weg von fachlich orientierter Anwendungsprogammierung).

wayne_757 · 24. Juni 2015

Faust2011 schrieb:
Nicht jedes Programm besteht primär aus Nebenläufigkeit und Ressourcen-Sharing.

Auf den ersten Blick ist diese Aussage korrekt.

Leider kommen die Posix Signale aber genau deshalb ins Spiel, weil man eine Pseudo Nebenläufigkeit erreichen wollte. Das war in den 80ern vielleicht ein tolles Konzept. Heute ist das einfach nur "broken by design", kaum korrekt handlebar.

Viele kritische Applikationen benötigen mehrere Threads um die Resourcen eines Systems sinnvoll auslasten zu können, wie z.B. ein Webserver oder Datenbank Server. Wenn so eine wichtige Applikation innerhalb eines solch kaputten Ökosystems läuft dann wird mir echt schlecht.

Ein Beispiel wie kaputt das Linuxsystem ist:
Um einen Prozess starten zu können benötige ich fork(). Damit fork() auch ja immer schön funktioniert wurde für diesen Vorgang Memory overcommit + Copy on Write implementiert. Ein Betriebssystem bei dem mehr Speicher allokiert wird, als vorhanden klingt absurd, ist absurd und ist so real in Linux vorhanden. Man muss also immer hoffen (ja wirklich hoffen, bestimmen geht nicht), dass dem System noch genügend RAM zur Verfügung steht. Ansonsten schlägt der Out of Memory Killer zu und beendet irgendeinen Prozess (ja, es muss nicht mal der sein der den ganzen Ram verschlingt, kann auch der eigene sein der fast nichts an Speicher belegt).

Sorry, aber das ist ein dahingefrickeltes System.

Faust2011 · 24. Juni 2015

wayne_757 schrieb:
Viele kritische Applikationen benötigen mehrere Threads um die Resourcen eines Systems sinnvoll auslasten zu können, wie z.B. ein Webserver oder Datenbank Server. Wenn so eine wichtige Applikation innerhalb eines solch kaputten Ökosystems läuft dann wird mir echt schlecht.

Schau Dir mal einen Apache Webserver oder den Servlet-Container Tomcat an: dort wird eben nicht pro Client ein Workerthread geforkt. Genau das wäre nämlich tödlich, stichwort Trashing auf der CPU. Viele Clients handelt man effektiv man asynchronem I/O, genau dafür bietet ein Unix-System den select()-Befehl, um nichtblockierend einen Filedescriptor zu fragen, ob gerade Daten gelesen/geschrieben werden müssen.

wayne_757 schrieb:
Ein Beispiel wie kaputt das Linuxsystem ist:
Um einen Prozess starten zu können benötige ich fork(). Damit fork() auch ja immer schön funktioniert wurde für diesen Vorgang Memory overcommit + Copy on Write implementiert. Ein Betriebssystem bei dem mehr Speicher allokiert wird, als vorhanden klingt absurd, ist absurd und ist so real in Linux vorhanden. Man muss also immer hoffen (ja wirklich hoffen, bestimmen geht nicht), dass dem System noch genügend RAM zur Verfügung steht. Ansonsten schlägt der Out of Memory Killer zu und beendet irgendeinen Prozess (ja, es muss nicht mal der sein der den ganzen Ram verschlingt, kann auch der eigene sein der fast nichts an Speicher belegt).

Hmm... genau anders rum. Das Problem, das Du ansprichst, ist eher die Ausnahme, weshalb man eben Copy-on-Write eingeführt hat. Weshalb sollte man denn bei einem fork() alle Speicherbereiche (eingeblendete Libs, ...) duplizieren? Erst wenn der Kindprozess tatächlich Zugriff braucht, dann wird die Speicherseite tatsächlich im System reserviert.

Wander · 24. Juni 2015

wayne_757 schrieb:
Ein Beispiel wie kaputt das Linuxsystem ist:
Um einen Prozess starten zu können benötige ich fork(). Damit fork() auch ja immer schön funktioniert wurde für diesen Vorgang Memory overcommit + Copy on Write implementiert. Ein Betriebssystem bei dem mehr Speicher allokiert wird, als vorhanden klingt absurd, ist absurd und ist so real in Linux vorhanden. Man muss also immer hoffen (ja wirklich hoffen, bestimmen geht nicht), dass dem System noch genügend RAM zur Verfügung steht. Ansonsten schlägt der Out of Memory Killer zu und beendet irgendeinen Prozess (ja, es muss nicht mal der sein der den ganzen Ram verschlingt, kann auch der eigene sein der fast nichts an Speicher belegt).

Sorry, aber das ist ein dahingefrickeltes System.

Kann es sein das du einfach die elementaren Bestandteile eines modernen Betriebssystems nicht verstanden hast? Insbesondere die virtuelle Speicherverwaltung? Virtueller Speicher ist nicht absurd, klingt nicht absurd und hat in der Praxis unglaublich viele Vorteile, deshalb findet man dieses Konzept auch in allen modernen Betriebssystemen.

Edit: Das gleich gilt natürlich auch für memory overcommit.

benneq · 24. Juni 2015

Ein weiterer Vorteil von kdbus ist natürlich, dass damit dbus schon während des Bootvorgangs zur Verfügung steht. Klar funktioniert Linux auch bisher ohne diesen Schnickschnack. Aber wenn so ein Feature erst mal da ist, finden sich sicherlich einige gute Anwendungsfälle dafür.

wayne_757 · 24. Juni 2015

Wander schrieb:
Edit: Das gleich gilt natürlich auch für memory overcommit.

Leider hast du noch nicht verstanden was memory overcommit bedeutet.
In einem normalen Betriebssystem gilt vereinfacht:
Zuweisbarer Speicher = RAM + Swap

unter Linux gilt:
Zuweisbarer Speicher = RAM + Swap + x

In der Hoffnung, dass x nie wirklich benötigt wird.
Hierzu ein einfaches Beispiel:

Code:

try
{
    std::vector<std::shared_ptr<...> > container;
    while(true)
   {
        container.push_back(std::make_shared<...>());
   }
}
catch(const std::bad_alloc&)
{
    std::cerr << "Out of memory occured";
}

Der Code oben führt in einem System ohne overcommit (z.B. Windows) immer zu der Ausgabe "Out of memory occured" und das Programm läuft danach korrekt weiter.

Unter Linux ist das reiner Zufall. Es kann der Text angezeigt werden, es kann aber auch der Prozess vom OOM Killer abgeschossen werden, der zuvor noch andere, unbeteiligte Prozesse beendet hat.
D.h. Linux ist an dieser Stelle kein deterministisches Betriebssystem und das ist nicht nur ein abstraktes sondern ganz konkretes Problem.

Schau Dir mal einen Apache Webserver oder den Servlet-Container Tomcat an: dort wird eben nicht pro Client ein Workerthread geforkt. Genau das wäre nämlich tödlich, stichwort Trashing auf der CPU. Viele Clients handelt man effektiv man asynchronem I/O, genau dafür bietet ein Unix-System den select()-Befehl, um nichtblockierend einen Filedescriptor zu fragen, ob gerade Daten gelesen/geschrieben werden müssen.

Zum Beispiel muss für jeden CGI Request geforkt werden. Bis Kernel 2.6.x (Einführung von FD_CLOEXEC) war es in einer Multithreaded Applikation wie dem Apache unter Linux technisch unmöglich Alle Filedescriptoren für den CGI Prozess korrekt zu schließen.

Hmm... genau anders rum. Das Problem, das Du ansprichst, ist eher die Ausnahme, weshalb man eben Copy-on-Write eingeführt hat. Weshalb sollte man denn bei einem fork() alle Speicherbereiche (eingeblendete Libs, ...) duplizieren? Erst wenn der Kindprozess tatächlich Zugriff braucht, dann wird die Speicherseite tatsächlich im System reserviert.

Das Stichwort lautet Determinismus. (Erläuterung steht weiter oben bereits)

Man hat hier ziemlich viel geopfert, nur um fork() ohne exec() ausführen zu können. Für einen Edge-case den quasi niemand benötigt (es gibt keinen use-case für fork() ohne exec(), dass man nicht anders sinnvoller lösen kann).

Camicace · 24. Juni 2015

Ich bitte darum, dass Wort DURCHWINKEN nicht mehr zu verwenden. Da bekomm ich einen Igel im Nacken und hat, da in der Politik oft real getan wird...Gesetzen zuzustimmen, ohne, dass jemand weiß, was der Inhalt ist, einen sehr Faden Beigeschmack. Ob in der Linux-Welt den Kernel betreffend sowas überhaupt gemacht wird, glaube ich auch kaum. Dank.

foofoobar · 25. Juni 2015

wayne_757 schrieb:
- fork+overcommit
- fork+exec+file descriptors

Welches andere Design würde die gleiche oder bessere Flexibilität von fork() & exec() bieten ohne den (ohnehin nur virtuellen) Ressourcenverbrauch?

Ergänzung (25. Juni 2015)

wayne_757 schrieb:
Ein Beispiel wie kaputt das Linuxsystem ist:
Um einen Prozess starten zu können benötige ich fork(). Damit fork() auch ja immer schön funktioniert wurde für diesen Vorgang Memory overcommit + Copy on Write implementiert. Ein Betriebssystem bei dem mehr Speicher allokiert wird, als vorhanden klingt absurd, ist absurd und ist so real in Linux vorhanden. Man muss also immer hoffen (ja wirklich hoffen, bestimmen geht nicht), dass dem System noch genügend RAM zur Verfügung steht. Ansonsten schlägt der Out of Memory Killer zu und beendet irgendeinen Prozess (ja, es muss nicht mal der sein der den ganzen Ram verschlingt, kann auch der eigene sein der fast nichts an Speicher belegt).

Sorry, aber das ist ein dahingefrickeltes System.

Memory overcommit ist keine Voraussetzung für fork() & exec(), es ist abschaltbar.
COW ist auch keine Voraussetzung für fork() & exec(), ansonsten würde es auf Systemen ohne MMU nicht laufen (µcLinux), COW beschleunigt fork() & exec(). BTW: Auch Windows macht COW, ansonsten würde mmap() unter Windows nicht vernüftig (langsam und eingeschränkt) laufen.

Wander · 25. Juni 2015

wayne_757 schrieb:
Leider hast du noch nicht verstanden was memory overcommit bedeutet.
In einem normalen Betriebssystem gilt vereinfacht:
Zuweisbarer Speicher = RAM + Swap

unter Linux gilt:
Zuweisbarer Speicher = RAM + Swap + x

In der Hoffnung, dass x nie wirklich benötigt wird.
Hierzu ein einfaches Beispiel:

Code:

try { std::vector<std::shared_ptr<...> > container; while(true) { container.push_back(std::make_shared<...>()); } } catch(const std::bad_alloc&) { std::cerr << "Out of memory occured"; }

Der Code oben führt in einem System ohne overcommit (z.B. Windows) immer zu der Ausgabe "Out of memory occured" und das Programm läuft danach korrekt weiter.

Unter Linux ist das reiner Zufall. Es kann der Text angezeigt werden, es kann aber auch der Prozess vom OOM Killer abgeschossen werden, der zuvor noch andere, unbeteiligte Prozesse beendet hat.
D.h. Linux ist an dieser Stelle kein deterministisches Betriebssystem und das ist nicht nur ein abstraktes sondern ganz konkretes Problem.

Natürlich weiß ich was memory overcommit bedeutet. Du hängst dich hier aber an einem Nachteil auf ohne die zahlreichen Vorteile von memory overcommit zu nennen; z.B. wird fork billiger und es folgt eine bessere Auslastung der Systemresourcen. Abgesehen davon ist dieses Verhalten natürlich deaktivierbar. Insofern verstehe ich noch weniger wo dein Problem ist.

Tuxman · 25. Juni 2015

wayne_757 schrieb:
Statt sich von Unix zu emanzipieren, hat man von dort sämtliche Designschwächen übernommen.

Das korrigiert Lennart ja gerade, indem er die Designschwäche von Microsoft (den alles steuernden Überprozess "svchost", äh, "systemd") reinflanschen will.

ShalokShalom · 25. Juni 2015

Systemd kommt nicht in den Kernel und Lennart flanscht das auch sonst nirgenst rein, er ist der Hauptentwickler.
Integriert wird es von den Distributionen und die machen das freiwillig.

News Linux: Linus Torvalds zu den Chancen von Kdbus im Kernel

Commander

Commander

Commodore

HTTP 418 - I'm a teapot

Admiral

Lieutenant

Commodore

Admiral

wayne_757

Gast

HTTP 418 - I'm a teapot

wayne_757

Gast

HTTP 418 - I'm a teapot

Ensign

Fleet Admiral

wayne_757

Gast

Banned

Commander

Ensign

Banned

Cadet 1st Year

Ähnliche Themen

Passend zum Thema