11 ms·

It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442 http://thread.gmane.org/gmane.linux.kernel/1930358/focus

by vidoc 11y ago

It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937442 http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.

deng 11y ago
That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.
- lmilcin 11y ago
  I would expect any half decent HTTP server to be able to handle more messages per second than that. If that is going to be the future fabric underlying all application ecosystem on Linux I would be as wary of it as Linus is. I will put it another way: if it can't be more performant than a simple HTTP client/server it doesn't deserve to be included into mainline kernel especially when the costs are so high.
  - azernik 11y ago
    Well, he's not claiming that kdbus is that slow. He's claiming that kdbus is faster not because it's in the kernel, but because it's not shitty code like userspace dbus (completely different implementation).
- fulafel 11y ago
  So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?
  - deng 11y ago
    IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.
    - semi-extrinsic 11y ago
      So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?
      - deng 11y ago
        I don't know. I'm not advocating kdbus for multimedia, I'm just repeating what I've heard. I think one of the driving forces behind kdbus is Samsung who are interested in kdbus for Tizen.
      - scrollaway 11y ago
        KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
        zurn 11y ago
        You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.
        detaro 11y ago
        I think the idea is "why use dbus to coordinate creation, rights assignment, ... of local sockets when you can push the data over dbus"?
        11y ago
- anon4 11y ago
  In that case, they should implement just the functionality they need in kernel, not a full DBUS implementation.
riking 11y ago
So, basically, systemd-bus would solve the problems even without kdbus, if it avoided all the extraneous memory allocations.
- audidude 11y ago
  I don't think Linus is up to date on libgio-2.0 (and the GDBus implementation). It does in fact use a SLAB, based on early kernel versions with per-thread allocation caching. As for avoiding utf8 validation, that would require being able to trust the sender/receiver. That, I believe, is a major bullet point of both memfd (sealing) and kdbus.
  - pdw 11y ago
    Linus' trace shows that 12% of the runtime is spent in libc's malloc and free. So yeah, there's a problem there.
- hp 11y ago
  kdbus really addresses a different performance issue than tuning mallocs and locks would. By tuning mallocs/locks/validation/parsing, you can reduce the overhead of each dbus send/receive, but with kdbus you remove half of the send/receives. So however fast your sends/receives are, kdbus will still make things faster by not doing as many of them.
  - hp 11y ago
    Here is the long version of that point: http://article.gmane.org/gmane.linux.kernel/1939651 http://article.gmane.org/gmane.linux.kernel/1939651

by vidoc 11y ago

deng 11y ago

That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.

lmilcin 11y ago
I would expect any half decent HTTP server to be able to handle more messages per second than that. If that is going to be the future fabric underlying all application ecosystem on Linux I would be as wary of it as Linus is. I will put it another way: if it can't be more performant than a simple HTTP client/server it doesn't deserve to be included into mainline kernel especially when the costs are so high.
- azernik 11y ago
  Well, he's not claiming that kdbus is that slow. He's claiming that kdbus is faster not because it's in the kernel, but because it's not shitty code like userspace dbus (completely different implementation).
fulafel 11y ago
So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?
- deng 11y ago
  IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.
  - semi-extrinsic 11y ago
    So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?
    - deng 11y ago
      I don't know. I'm not advocating kdbus for multimedia, I'm just repeating what I've heard. I think one of the driving forces behind kdbus is Samsung who are interested in kdbus for Tizen.
    - scrollaway 11y ago
      KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
      - zurn 11y ago
        You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.
        detaro 11y ago
        I think the idea is "why use dbus to coordinate creation, rights assignment, ... of local sockets when you can push the data over dbus"?
        11y ago
anon4 11y ago
In that case, they should implement just the functionality they need in kernel, not a full DBUS implementation.

riking 11y ago

So, basically, systemd-bus would solve the problems even without kdbus, if it avoided all the extraneous memory allocations.

audidude 11y ago
I don't think Linus is up to date on libgio-2.0 (and the GDBus implementation). It does in fact use a SLAB, based on early kernel versions with per-thread allocation caching. As for avoiding utf8 validation, that would require being able to trust the sender/receiver. That, I believe, is a major bullet point of both memfd (sealing) and kdbus.
- pdw 11y ago
  Linus' trace shows that 12% of the runtime is spent in libc's malloc and free. So yeah, there's a problem there.
hp 11y ago
kdbus really addresses a different performance issue than tuning mallocs and locks would. By tuning mallocs/locks/validation/parsing, you can reduce the overhead of each dbus send/receive, but with kdbus you remove half of the send/receives. So however fast your sends/receives are, kdbus will still make things faster by not doing as many of them.
- hp 11y ago
  Here is the long version of that point: http://article.gmane.org/gmane.linux.kernel/1939651 http://article.gmane.org/gmane.linux.kernel/1939651