> 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.
You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.
If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?
> If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning.
Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything.
There is obviously a lot of general inefficiency in the userland libraries but not in the design of it.
You're talking about memfd, I think? That has nothing to do with kdbus in particular. It's an independent syscall that replaces many use cases for splice/vmsplice, even though it was introduced as part of the kdbus project - it's still a separate thing.
> You're talking about memfd, I think? That has nothing to do with kdbus in particular. It's an independent syscall that replaces many use cases for splice/vmsplice, even though it was introduced as part of the kdbus project - it's still a separate thing.
That was created for KDBUS but has more use than than being used for KDBUS exclusively. It still was written for KDBUS.
And so it was accepted and merged. That something good came out of kdbus is excellent, but that's no justification to merge in the whole package. A ton of proposed kernel additions end up like this - a few good ideas refined and accepted, and the rest thrown out.
the trace isn't dbus itself, it's a particular client program using the gdbus binding. The gdbus binding uses a lot of malloc and threads, and this particular client program is all blocking round trips.
>You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.
The real problem is he doesn't give any data for volume/bandwidth processed in his case.
I don't see why a "security policy driven message bus" would be more expensive than what he describes (unzipping, business rules encorcement, analyzing, etc).
> I don't see why a "security policy driven message bus" would be more expensive than what he describes (unzipping, business rules encorcement, analyzing, etc).
It was in comparison with an HTTP server. I did not read much about the mail thread but from what I can tell it essentially benchmarks the uninteresting part of DBUS which is the part that runs in userspace. That's old and definitely needs improvements, but not the design of it. In fact, the design of KDBUS or the DBUS dispatching core is from what I can tell quite intelligent and makes sense from a performance point of view.
Without a doubt there are a lot of old bells and whistles attached to DBUS which need rewriting.
You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.