Announcement

Collapse
No announcement yet.

Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

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

  • Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

    Phoronix: Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

    With the new Linux kernel mailing list thread about the prospects of merging KDBUS into the mainline Linux kernel, Linus Torvalds has provided his thoughts on the matter for this controversial feature backed by systemd developers for trying to provide a high-performance, kernel-based IPC solution...

    http://www.phoronix.com/scan.php?pag...Linus-Comments

  • #2
    Linus is rather predictable in this regard. For him it is just business as usual and he is making no special rules for kdbus. If kdbus is getting mainlined, it is getting mainlined for exactly the same reasons as other kernel features. Linus's lieutenants that have knowledge in that particular domain have to gives their "thumbs up". It has has to be a user-driven feature that solves real world problems, though sometimes new features are given the benefit of doubt whether they will be widely used. Some serious commitment to maintaining any non-trivial feature is also a priority.

    While Linus have always been pragmatic, he have always regarded speed and efficency as important features of the kernel, since it was those virtues that drove Linux development forward in the beginning. Theoretical advantages, especially speed related, have never really impressed him. The kdbus developers could have done their homework better in this regard.

    Linus is _only_ giving his general intention of merging it. kdbus still have to pass every test that other prominent features have to go through.
    On the other hand, Linus have now signaled several times, that general handwaving against kdbus isn't enough; it has to be actionable criticism before he bothers to listen.

    Comment


    • #3
      Why push all to kernel space? Minix has only 4000 code lines, all the rest is in user space.- It even claims to be self healing, ie when a driver dies it gets restarted etc.

      Comment


      • #4
        Linus is obviosly right, changleog should just include this: "We like to merge this shit soon, because we plan to abandon userspace variant sooner. There is no any performance or any other real improvment, only bugs... and this is just because we like to push things on people. Of course, this in not the first nor last time we plan to do this, as it is proven that our users are either brainwashed or pure masochists".
        Last edited by dungeon; 24 June 2015, 02:07 AM.

        Comment


        • #5
          Just a reminder: the fact that code is mainlined does not mean every distribution needs to include it. While it's true that Linux has a monolithic architecture, it is still modular, and not every module has to be included everywhere. For example, Android would probably not include KDBUS.

          But it does mean that the code becomes a responsibility of the Linux team. And of course, it does imply that it would be available on most "full" (desktop) distributions of Linux.

          The arguments about performance here are a bit subtle. The issue is not a general performance improvement, but a specific and major improvement in the case of dbus messages that include a *lot* of data. Kernel-mode can do things with memory that user-mode just can't. Traditionally, dbus has not involved sending a lot of data for this reason, but KDBUS will open open new possibilities for IPC.

          I'm not sure exactly what systemd has planned for this feature. Perhaps it would be possible to send big dumps for the case of error handling?

          Comment


          • #6
            My bet is to further secure the boot process.
            They have stated they are depreciating udev for their own sd-device and I presume this with be kdbus enabled

            Lying shits really... They promised certain things when they merged in udev and they are going against it to force distro/users hands

            Comment


            • #7
              Someone remembers the first days of systemd? They spreaded the mythos that systemd is a lot faster than other inits. And did a showcase where systemd starts without X and Network etc etc. On a regular desktop its still as slow as other inits. But that was enough to implement the mythos that systemd is a) faster and b) all about speed. So its a very simple tactic but that doesnt work with Linus.

              They even try the systemd-pushed-through-the-gnome-backdoor-into-debian now again. But that doesnt work with Linus.

              So i understand why Poettering always undermines Linus position because of linus behaviour, where Poettering himself is known to not only send the nicest words. But linus seems to be the last tower of strengh against all that bad tactics.

              Comment


              • #8
                Originally posted by emblemparade View Post
                For example, Android would probably not include KDBUS.
                Think again.
                https://lwn.net/Articles/551969/

                > The plan is to merge kdbus when it is "ready", which he hopes will be before the end of the year. His goal, though it is not a general project goal, is to replace Android's binder with kdbus. He has talked to the binder people at Google and they are amenable to that, as it would allow them to delete a bunch of code they are currently carrying in their trees.

                Comment


                • #9
                  Originally posted by k1l_ View Post
                  They even try the systemd-pushed-through-the-gnome-backdoor-into-debian now again. But that doesnt work with Linus.
                  So i understand why Poettering always undermines Linus position because of linus behaviour, where Poettering himself is known to not only send the nicest words. But linus seems to be the last tower of strengh against all that bad tactics.
                  you need to do some research if you are saying that gnome was forced to use systemd/logind, LPoettering wrote a library for Gnome to sidestep systemd/logind but Gnome decided not to use it.

                  Comment


                  • #10
                    Originally posted by doom_Oo7 View Post
                    my god these people are like 5yo

                    "There is also a one-copy message passing mechanism that Tejun Heo and Sievers came up with. Heo actually got zero-copy working, but it was "even scarier", so they decided against using it. Effectively, with one-copy, the kernel copies the message from user space directly into the receive buffer for the destination process."

                    misusing the name "zero-copy" for... 5(?) years
                    and now inventing "one-copy", that is half way between normal read/write (but requires synchronisation at the destination)

                    meanwhile ringbuffers and other forms of shm are standard practice
                    hell, even X could support shm comunication
                    Last edited by gens; 24 June 2015, 05:03 AM.

                    Comment

                    Working...
                    X