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

[fethomm]

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]

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]

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]

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]

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]

Tja Programmierkot performed halt nicht gut.

 

[Miuwa]

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]

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

 

[wayne_757]

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]

- 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]

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]

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.

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]

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]

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]

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:

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]

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]

- 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)

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]

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:

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]

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]

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.