Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“DBus is seriously screwed up”

thread.gmane.org

Post reply on HN
Print view View original

31–40 of 209 posts

Re: “DBus is seriously screwed up”

#31

Post by deng »

fulafel wrote: post #27
deng wrote: post #17

Earlier quoted context omitted.

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.

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?

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

Re: “DBus is seriously screwed up”

#32

Post by pjc50 »

Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy.

The most unixy solution is buried at the bottom of this thread, from Plan 9: https://news.ycombinator.com/item?id=9450988 ; but if that's not popular, then I think what people actually want for desktop purposes is an equivalent of the Windows PostMessage system.

Re: “DBus is seriously screwed up”

#33

Post by lumpypua »

vidoc wrote: post #11
lclarkmichalek wrote: post #8

Earlier quoted context omitted.

Naive REST (HTTP, JSON) isn't exactly known for its performance

Agreed, that said, I'm kind of wondering what non-naive (smart?) REST is, no sarcasms :P

You can use REST architectural principles with a faster transport and serialization. For example, using a REST style API for a messagepack or thrift RPC service.

Re: “DBus is seriously screwed up”

#34

Post by audidude »

riking wrote: post #20
vidoc wrote: post #13

It all started with a microbenchmark: 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.

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

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.

Re: “DBus is seriously screwed up”

#35

Post by thezilch »

lclarkmichalek wrote: post #8
castell wrote: post #5

> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model faile…

Naive REST (HTTP, JSON) isn't exactly known for its performance

Seems to be doing better than the speeds sited by the KDBUS thread -- https://www.techempower.com/benchmarks/#section=data-r10&tes...

Re: “DBus is seriously screwed up”

#36

Post by lmilcin »

It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that.

Heck, I have worked on an algorithmic trading platform that in the limit of 5us receives market data, dedups it (multiple multicast streams for redundancy), uncompresses it (fricking zlib), parses it, analyzes it, sends to multiple algorithms which decide if current market situation matches certain rules, decides and fills market order, the order gets inspected by independent mechanism to stop the algorithm if it malfunctions, and only then it gets sent to market, over TCP, which is another form of IPC.

All in the span of fricking 5us which is 40 times less than the benchmark suggests for this simple task. Granted, the algorithmic trading world goes to great lengths to avoid overhead including kernel overhead any kind of task switiching, branch prediction fails, etc. But still, come on, guys...

Re: “DBus is seriously screwed up”

#37

Post by thaumaturgy »

masklinn wrote: post #19
A_COMPUTER wrote: post #16

Earlier quoted context omitted.

He does seem to be saying that kdbus is pointless since those fixes would be in userspace where it's spending most of its time. Or am I misunderstanding?

The point of kdbus is to do dbus in kernel space. The one spending lots of time in userspace overhead (not doing actually useful work) is regular dbus. Linus is saying that kdbus is pointless because its performance gains don't come from being in-kernel, they come from the code not being a complete shit-show, and he believes the same performance should be achievable by fixing regular userspace dbus.

Well, the code review of kdbus in the rest of that thread would argue that its code is a shit-show, it just happens to be a faster shit-show than userspace dbus.

Re: “DBus is seriously screwed up”

#38

Post by lclarkmichalek »

thezilch wrote: post #35
lclarkmichalek wrote: post #8

Earlier quoted context omitted.

Naive REST (HTTP, JSON) isn't exactly known for its performance

Seems to be doing better than the speeds sited by the KDBUS thread -- https://www.techempower.com/benchmarks/#section=data-r10&tes...

The fact that one slow implementation is slower than another slow implementation says nothing.

Re: “DBus is seriously screwed up”

#39

Post by semi-extrinsic »

deng wrote: post #31
fulafel wrote: post #27

Earlier quoted context omitted.

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?

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?

Re: “DBus is seriously screwed up”

#40

Post by audidude »

deng wrote: post #31
fulafel wrote: post #27

Earlier quoted context omitted.

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?

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

I think wayland was one possibility.
Post reply on HN