Login
Newsletter
Werbung

Thema: Kdbus in Fedora Rawhide zum Test

14 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von X-Män am Fr, 31. Juli 2015 um 10:29 #

Ich habe darüber bereits gestern auf anderen Seiten darüber gelesen und stelle mir seit dem die Frage, inwiefern dies auf die allgemeine Performanz des Kernels schlägt.

Wenn nun alle möglichen und unmöglichen Kernelprozesse an den KDBUS senden (und empfangen), dann geht das doch meiner Ansicht nach auf die Ausführungsgeschwindigkeit des Gesamtkernels oder ?

Es ist doch ein gewaltiger Unterschied, ob eine Subroutine (Beispiel das USB Subsystem) innerhalb von 64 Microsekunden aus der Routine vom Aufruf bis zum Return zurückkehrt (Ausführungsgeschwindigkeit) oder erst nach 85 Microsekunden (weil der KDBUS noch Meldung machen muss).

Betrachten wir das Gesamtbild des Kernels, dann könnte ich mir Performanzeinbußen durch das implementierte KDBUS sehr gut vorstellen.

[
| Versenden | Drucken ]
  • 1
    Von hjb am Fr, 31. Juli 2015 um 10:54 #

    Wieviel Prozent der CPU-Zeit benötigt D-Bus auf einem normalen System? Es ist nicht mal messbar. KDBus ist noch mal schätzungsweise 20-mal schneller.

    [
    | Versenden | Drucken ]
    • 1
      Von X-Män am Fr, 31. Juli 2015 um 11:15 #

      Das mit deinem geschätzten 20x schneller halte ich für ein Gerücht. Je nach Architektur und Optimierung des C Codes wird doch ein differenzierter Maschinencode generiert.

      Es ist ein Unterschied, ob ich einen (Am Beispiel von 680x0 Code) 'mulu' Befehl benutzt, welches 70+ Taktzyklen verwendet oder das Ganze mit einem 'swap' und zwei 'lsl' Befehlen substituiere.

      Gut das ist unerheblich für dieses Beispiel. Es ist jedoch ein gewaltiger Unterschied, wenn alle Subprozesse des Kernels an den KDBUS kommunizieren und sich in der Gesamtsumme die Zyklen der ausgeführten Opcodes kumulieren.

      Es gibt durchaus Systeme bzw. Programme die kein DBUS einsetzen.

      Für mich sieht das eher aus, als wenn man Linus Torvalds und alle andere Kernelentwickler mit einer Mistforke von Hinten durchs Auge, durch 2 Türen und einem Kopf das KDBUS in die Aufnahme des Kernels "erpressen" will.

      Wenn man es in Red Hat per Patches (und vollkommen ungetestet) aufschwatzt, die Entwickler (vornehmlich Gnome (Red Hat)) und andere das "gezwungenermaßen" nutzen, man eine ähnliche Situation schafft, wie es mit udev und systemd geschah.

      Damit isoliert man andere unixoide Systeme noch mehr ins Abseits.

      Stellt sich die Frage, was Linux noch mit Linux zu tun haben wird in 5-10 Jahren.

      [
      | Versenden | Drucken ]
      • 1
        Von glasen am Fr, 31. Juli 2015 um 11:29 #

        Es gibt durchaus Systeme bzw. Programme die kein DBUS einsetzen.
        Diese müssen dann ja auch kein KDBUS in den Kernel einkompilieren.

        [
        | Versenden | Drucken ]
        1
        Von krake am Fr, 31. Juli 2015 um 13:51 #

        Es ist jedoch ein gewaltiger Unterschied, wenn alle Subprozesse des Kernels an den KDBUS kommunizieren

        Schon möglich, aber warum sollten die das auf einmal tun?

        KDBUS ist ja nicht für Kommunikation im Kernel oder zwischen Kernel und Userspace.

        Es ist doch nur der kernelseitiger Teil für Userspace-Userspace Kommunikation

        [
        | Versenden | Drucken ]
        • 0
          Von schmidicom am Fr, 31. Juli 2015 um 14:29 #

          Es könnte aber so (Kernel - Userspace) verwendet werden, und daher ist es nicht auszuschließen dass das irgendwann mal vorkommen wird. Aber selbst dann wird es vermutlich eher eine Seltenheit irgend eines Hardwareexoten sein und gegenüber den vielen Clients aus dem Userspace kaum auffallen..

          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 31. Jul 2015 um 14:29.
          [
          | Versenden | Drucken ]
    0
    Von schmidicom am Fr, 31. Juli 2015 um 11:34 #

    Greg schrieb mal das der Geschwindigkeitsvorteil gar nicht so wichtig sei, sondern viel mehr das der kdbus im Startprozess zu einem früherem Zeitpunkt zur Verfügung steht und dadurch einiges einfacher würde.

    Und ich halte Greg für vertrauenswürdig/kompetent genug das ich ihm das so glaube.

    [
    | Versenden | Drucken ]
    • 1
      Von Tuxi am Mo, 3. August 2015 um 11:11 #

      Und genau das sind auch die richtigen Argumente. Es ist etwas Schade das man die eigentlichen, durchaus sehr guten, Gründe durch einen erwiesen falschen Grund (Performanz) abgewertet hat.

      [
      | Versenden | Drucken ]
      • 0
        Von schmidicom am Mo, 3. August 2015 um 11:20 #

        War bei systemd eine Zeit lang doch auch so und auch wenn es dank funktionierender Parallelisierung tatsächlich schneller ist so liegen die viel wichtigeren Vorteile ja eigentlich wo anders.

        Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Aug 2015 um 11:21.
        [
        | Versenden | Drucken ]
1
Von X-Män am Fr, 31. Juli 2015 um 10:30 #

Ich habe darüber bereits gestern auf anderen Seiten darüber gelesen und stelle mir seit dem die Frage, inwiefern dies auf die allgemeine Performanz des Kernels schlägt.

Wenn nun alle möglichen und unmöglichen Kernelprozesse an den KDBUS senden (und empfangen), dann geht das doch meiner Ansicht nach auf die Ausführungsgeschwindigkeit des Gesamtkernels oder ?

Es ist doch ein gewaltiger Unterschied, ob eine Subroutine (Beispiel das USB Subsystem) innerhalb von 64 Microsekunden aus der Routine vom Aufruf bis zum Return zurückkehrt (Ausführungsgeschwindigkeit) oder erst nach 85 Microsekunden (weil der KDBUS noch Meldung machen muss).

Betrachten wir das Gesamtbild des Kernels, dann könnte ich mir Performanzeinbußen durch das implementierte KDBUS sehr gut vorstellen.

[
| Versenden | Drucken ]
  • 1
    Von Le C am Fr, 31. Juli 2015 um 23:02 #

    Der Kernel is kein einziger prozess sonder besteht auch aus verschiedenen threads. KDBus kann also unabhaengig vom Rest der kernels arbeiten. Der network stack macht den kernel ja auch nicht langsamer... Der unterschied ist das der kernel mehr privileges hat. Ein Vorteil von kdbus ist das grosse daten menge direkt zwischen prozessen ausgetauscht werden koennen. Ausserhalb des kernel muessen sie erst zwischen den prozessen kopiert werden. Ich denke auch eine transaction in kdbus sollte weniger syscalls (user space kernel) brauchen als eine entsprechende dbus operation. Also wuerd ich sagen der kernel wird entlastet...

    [
    | Versenden | Drucken ]
1
Von Anonymous am Fr, 31. Juli 2015 um 11:55 #

https://blogs.gentoo.org/johu/2015/07/10/plasma-5-and-kdbus-testing/

Hat es schon jemand getestet, Erfahrungen? Seit Kernel 4.1.3 startet es ohne Fehlermeldung.

[
| Versenden | Drucken ]
  • 1
    Von cyberpatrol am Mo, 3. August 2015 um 12:54 #

    Um mal Missverständnisse aus dem Weg zu räumen. kdbus gibts bei Gentoo nur mit USE="kdbus". Per Default wird kdbus bei Gentoo erfreulicher Weise nicht installiert, also noch nicht mal der Kernelpatch.

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Aug 2015 um 12:56.
    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung