Announcement

Collapse
No announcement yet.

Bringing D-Bus Into The Linux Kernel

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

  • Bringing D-Bus Into The Linux Kernel

    Phoronix: Bringing D-Bus Into The Linux Kernel

    Alban Crequy, a Maemo developer, for the past several weeks have been working on bringing D-Bus directly into the Linux kernel. Why? Huge performance improvements...

    http://www.phoronix.com/vr.php?view=ODYwNA

  • #2
    My interpretation of the numbers is different:

    The speedup by a factor of two or three is only valid for a synthetic test case (ping-pong).

    The benchmarks for real-world-cases show a speedup of 25 percent or less.

    KDBus still needs a DBus daemon which handles a lot of stuff, the kernel-code is insecure and the speedup not that big. I would like to see how much can be improved by tuning the daemon alone before anybody starts putting user-space code into the kernel.

    Kernel code complicates development a lot - it takes lots of time until changes are accepted and distributed to all users. One has to reboot. A daemon can be replaced anytime. I am not even sure Linus and his friends will accept these patches.

    Finally, to say it in the words of another user: "d-bus is a horrible monster and cramming it into the kernel to save one second of jabber connectivity is one of the most brain-dead efforts Iíve seen in years."

    Comment


    • #3
      Ewww. D-Bus itself is completely unnecessary, keep that thing out of the kernel.

      Comment


      • #4
        Originally posted by sturmflut View Post
        My interpretation of the numbers is different:

        The speedup by a factor of two or three is only valid for a synthetic test case (ping-pong).

        The benchmarks for real-world-cases show a speedup of 25 percent or less.

        KDBus still needs a DBus daemon which handles a lot of stuff, the kernel-code is insecure and the speedup not that big. I would like to see how much can be improved by tuning the daemon alone before anybody starts putting user-space code into the kernel.

        Kernel code complicates development a lot - it takes lots of time until changes are accepted and distributed to all users. One has to reboot. A daemon can be replaced anytime. I am not even sure Linus and his friends will accept these patches.

        Finally, to say it in the words of another user: "d-bus is a horrible monster and cramming it into the kernel to save one second of jabber connectivity is one of the most brain-dead efforts Iíve seen in years."
        It makes as much sense as it does to move X Windows into the kernel.

        Originally posted by curaga View Post
        Ewww. D-Bus itself is completely unnecessary, keep that thing out of the kernel.
        To be fair, it would be used only for userland processes. Kernel components would not use it for intra-kernel communication.

        Comment


        • #5
          Originally posted by Shining Arcanine View Post
          It makes as much sense as it does to move X Windows into the kernel.
          A commercial company already did that with a proprietary kernel module:
          http://www.microxwin.com/

          Comment


          • #6
            I seriously doubt anyone is using D-Bus for performance-critical applications...

            I don't agree though that it's unnecessary, a monster or anything. What's wrong with it? I've used it -- it's easy and works well.

            Comment


            • #7
              I bet KDE would also be extremely snappy if moved into the kernel ;-)

              Comment


              • #8
                IMHO that's a horrible idea because that would freeze the API forever. Speed-improvements are somewhat minor, unless you start sending thousands of messages per second. Can anyone name a good use-case where you need both the flexibility of DBus and the speed of, say, a standard pipe?

                As of now, DBus restricts messages to a single computer, making it unsuitable for an X environment where several apps may run on a different machine (see the new systray protocol).
                In the long term, we would either need to route DBus through the X protocol or drop DBus for all uses where it's not suitable. The latter isn't going to happen; those that use DBus for such uses already decided not to care about remote X or multiple X sessions per user.

                In other words, I'd like to see DBusRemote working before anything moves to the kernel.

                Comment


                • #9
                  What the hell is the point, other than a small gain for Maemo devices?

                  Kill it! Kill it with fire!

                  Comment


                  • #10
                    Originally posted by brent View Post
                    I seriously doubt anyone is using D-Bus for performance-critical applications...
                    Uhhmm... KDE? I'm not sure, but I consider software I'm using on a daily basis "performance-critical". Sure, D-Bus is probably the least bottleneck KDE has, but performance improvement are always a good idea.

                    As for development/API, D-Bus has been more or less frozen thanks to the freedesktop spec they are following. Sure there are exceptions, but it's not like the kernel really has that much of a frozen API either, you can always be forward-compatible.

                    Comment


                    • #11
                      Originally posted by pingufunkybeat View Post
                      What the hell is the point, other than a small gain for Maemo devices?

                      Kill it! Kill it with fire!
                      With plasma fire you mean. And all the devs who had this idea. Then spread the dust through space and lets never talk about it again!

                      Comment


                      • #12
                        Why would this benefit performance exactly? What sort of overhead is intrinsically connected to user-space code (i.e. most of the code you run) aside from the few cycles required to switch x86 into protected mode? If there's that much to be gained by moving stuff into the kernel then I'd call that a design flaw elsewhere having nothing to do with dbus.

                        Comment


                        • #13
                          Originally posted by fabiank22 View Post
                          Uhhmm... KDE?
                          Actually I'm only seeing a handful of messages per minute on the session bus (and almost none on the system bus), mostly kwin activations and kopete stuff.
                          I'm surprised that dbus can actually become a bottleneck...

                          Comment


                          • #14
                            Step 1: design Yet Another Ugly and Overengineered IPC System (YAUOIS)
                            Step 2: move it to the kernel to overcome the problems caused by bad design decisions.

                            Seriously, I doubt this will be accepted. Android is already trying to push in their own (YAUOIS)...how many of the do we need? Can't D-Bus use the Android crap?

                            Comment


                            • #15
                              @diegocg

                              Definitely. You forgot step 1.5: Make it Yet Another Daemon.

                              So that people who just want to pass messages can get more resource usage, always there for you, up and running.

                              Comment

                              Working...
                              X