Announcement

Collapse
No announcement yet.

Bringing D-Bus Into The Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by rohcQaH View Post
    There are more messages between Firefox and X than D-Bus messages on my whole desktop. If it's just about eliminating the system calls and memory copies, moving either Firefox or X into the kernel would save way more CPU cycles than moving D-Bus.
    I don't think you understand what D-Bus is really, so let's start from the ground up.

    Every application talks to the Display Server, calling repaints and everything, but those are not kernel messages/kernel mode switches, that is user mode communication. Inital Modesetting is one of the few things that the X-Server did in Kernel Mode(Thus requiring root rights), but we are moving away from that.

    D-Bus however is Daemon for Applications to talk to each other over this protocol instead of the crazy way of shared memory. So if, let's say Amarok changes the song played it calls out a D-Bus Message, and the Now Listening-Plugin of your instant messenger will pick it up. The daemon for D-Bus resides in User-Space, but messages between processes happen in Kernel-Space, so you have a context switch every time a message is send.

    Firefox communicating with X does not happen in Kernel-Mode. Sure your drivers may actually do some Hardware calls in Kernel-Mode, but once again, pushing Firefox into the kernel will not make it faster(or may make it faster due to other factors, threading and stuff like that, but can you spell security nightmare?)

    So yeah, D-Bus' only purpose makes him actively use Kernel-Space, and it's a cornerstone of the modern fs-ecosystem so why not merge it there?

    Comment


    • #32
      Hmm, isn't D-Bus supposed to be cross-platform? Moving some of it to the Linux kernel doesn't sound very helpful in that regard.

      Comment


      • #33
        fabiank22:

        You seem to believe that X and applications use a different communication mechanism, one that magically avoids system calls, memory copies and context switches. You're wrong.

        When X talks to the app it uses the same mechanism that amarok uses to talk to dbus_daemon, or that MineSweeper.exe uses to talk to wineserver. The overhead you're talking about is equally present in any kind of IPC, be it pipes or real network connections. That overhead has to be there to ensure security and a sane userspace API.

        (right, it's not present in SHM-hacks, but let's ignore those for obvious reasons.)

        Of course we can avoid this overhead by moving one end of the communication channel to kernel space. Moving Firefox would yield a large absolute speedup (a context switch and a few cycles for every message sent), but a marginal relative speedup (because message sending is just a very very small part of firefox).

        Moving D-Bus would yield a small absolute speedup, because typically only few messages are sent. Of course it's a large relative speedup if all you're looking at is a synthetic benchmark of D-Bus.


        I'd say that improving desktop speed by putting DBus somewhere it doesn't belong is about as smart as improving the fuel efficiency of a SUV by installing better blinker lights.

        Comment


        • #34
          Originally posted by fabiank22 View Post
          Firefox communicating with X does not happen in Kernel-Mode.
          So what exactly do you think happens every time the X11 client inside the GTK library used by Firefox calls send() or receive() on the UNIX socket connecting it to the X server?

          Surprise: Context switch to kernel mode.


          I would really like to see some profiling on the current dbus-daemon first which proves that those few context switches truly are the problem. X11 transmits far more messages via a similar mechanism, and it has been proven numerous times that UNIX socket communication does not account for performance problems.

          Comment


          • #35
            Originally posted by DeepDayze View Post
            DCOP is a KDE thing not a general userspace message bus and definitely old and has reached its limits, thus dbus was born. Also Gnome just started using dbus as well so it isn't just a KDE thing now any longer and it has gotten the same benefits as KDE did.
            Wrong on two counts - dbus was never "just a KDE thing", and Gnome certainly hasn't "just started" using it. The guys who built it (Havoc and co) were long-time Gnome developers, and it was being used in Gnome apps pretty much from the start.

            The difference is that KDE switched rather quickly from DCOP to dbus, while Gnome has had a much slower migration away from the old Bonobo frameworks - I think the panel applet API changes in the upcoming 2.32 release are the last piece of core code to be migrated...

            Comment


            • #36
              I doubt this patch is about the speed of D-bus, but I think it is all about reducing context switch when a phone is in standby mode.

              The power consumption of the N900, I have at most 2 days of battery.
              A lot of experiments to get better battery life from the Maemo Wiki are about reducing context switches when the phone is not active.

              Comment


              • #37
                Jesus, guys! Dbus is everywhere. 25% real world speedup? Get it here already!

                Oh it doesn't work remotely, so? Bringing it into the kernel doesn't mean that you have to use it or that it blocks you from using something else. I hope I need to remind no-one here that Linux on mda's is about a tenfold of the Linux desktop marketshare if not much greater, so why hate it if it saves you batterylife?

                If the Linux kernel gets too complicated then time for HURD; It runs and I ran it 4-5 years ago. So either Linux is a mess or it should get in there. Realy...

                Comment


                • #38
                  Originally posted by Delgarde View Post
                  The difference is that KDE switched rather quickly from DCOP to dbus, while Gnome has had a much slower migration away from the old Bonobo frameworks - I think the panel applet API changes in the upcoming 2.32 release are the last piece of core code to be migrated...
                  This is understandable, seeing how dbus was basically a drop-in replacement for dcop, working in almost exactly the same way (it was based on dcop concepts after all), while Bonobo was a mess which never worked in the first place.

                  Anyway, dbus is a free desktop standard, and making it Linux-only would be a really dumb thing to do.

                  Comment


                  • #39
                    Originally posted by Ikipou View Post
                    The power consumption of the N900, I have at most 2 days of battery.
                    A lot of experiments to get better battery life from the Maemo Wiki are about reducing context switches when the phone is not active.

                    Originally posted by V!NCENT View Post
                    Jesus, guys! Dbus is everywhere. 25% real world speedup? Get it here already!

                    (...)
                    so why hate it if it saves you batterylife?
                    Jesus!

                    Could we please gather some REAL numbers first, and make sure that all other parts of the dbus system are optimized? AFAICT the guy didn't even profile the application, and here he is claiming a kernel patch will solve everything.

                    Just look at his N900 benchmarks please: 10.000 ping-pong calls means 20.000 messages. The test takes about four seconds, which means a dbus round-trip takes just 400 microseconds - on a mobile CPU! Connecting to Jabber takes him twelve seconds. I heavily doubt connecting to Jabber generates 60.000 messages on dbus, so all this time must be spent somewhere else. The mentioned benchmark tool by Adrien Bustany doesn't build on Ubuntu 10.10 Beta, so I can't test it.

                    On every desktop system I've used to date dbus transports messages at an average rate of about one message every thirty seconds or less. Running KDE, network-manager and stuff.

                    I am absolutely sure dbus can be optimized in a number of other ways first. Like, finally find out why dbus is that much slower than CORBA or DCOP despite all three using UNIX sockets...

                    Comment


                    • #40
                      Originally posted by sturmflut View Post
                      So what exactly do you think happens every time the X11 client inside the GTK library used by Firefox calls send() or receive() on the UNIX socket connecting it to the X server?

                      Surprise: Context switch to kernel mode.
                      Okay, guess I was wrong on that one, however once again we are talking about libraries, so the things that would change when firefox is moved to the kernel would be: zero.
                      Because it's not Firefox that uses the socket, it's GTK2 or XUL or QT or whatever lib you're using.

                      Comment


                      • #41
                        Btw, what is wrong with IPC, which is already in the kernel? (At least I think it is.) I don't know much about the topic and wonder if there's something D-Bus does that IPC can't?

                        Comment


                        • #42
                          Originally posted by RealNC View Post
                          Btw, what is wrong with IPC, which is already in the kernel? (At least I think it is.) I don't know much about the topic and wonder if there's something D-Bus does that IPC can't?
                          I assume you're talking about Inter Process-Communication, and yes, that's been part of POSIX since forever. However you're mistaking methods and implementations.

                          D-Bus is a method of IPC, as for the advantages of using it:

                          Originally posted by Wikipedia
                          Messages received over a D-Bus connection get routed to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to users as if they are interacting with an object across the IPC connection, whether or not there is an object on the other side.

                          Comment


                          • #43
                            You guys seem to miss the point because almost everything these days uses dbus. So it is not _just_ Firefox or _just_ Jabber.

                            If what PinguFunkyBeat says is true, that dbus is unoptimized, then I do think that they should do some work there before taking it to the kernel.

                            Comment


                            • #44
                              Damn Edit Limit.

                              Anyway from the D-Bus faq:


                              How does D-Bus differ from other interprocess communication or networking protocols?


                              Keep in mind, it is not only an IPC system; it also includes lifecycle tracking, service activation, security policy, and other higher-level structure and assumptions.
                              And:

                              D-Bus communication with the intermediate bus daemon should be (and as last profiled, was) about twice as slow as one-to-one mode, because a round trip involves four socket reads/writes rather than two socket reads/writes.

                              The overhead comes from a couple of places; part of it is simply "abstraction penalty" (there are layers of code to support multiple main loops, multiple transport types, security, etc.). Probably the largest part comes from data validation (because the reference implementation does not trust incoming data). It would be simple to add a "no validation" mode, but probably not a good idea all things considered.

                              Raw bandwidth isn't the only concern; D-Bus is designed to enable asynchronous communication and avoid round trips. This is frequently a more important performance issue than throughput.

                              Comment


                              • #45
                                Originally posted by V!NCENT View Post
                                If what PinguFunkyBeat says is true, that dbus is unoptimized, then I do think that they should do some work there before taking it to the kernel.
                                From what I gather from [1] dbus not only validates, but also partially rewrites the messages as they pass through. In a RO scenario (which includes validation) it would be possible to use tee and splice to avoid the copy (but not the CS).

                                [1] http://alban.apinc.org/blog/2010/09/...kernel-faster/

                                Comment

                                Working...
                                X