“DBus is seriously screwed up”

Post by the_mitsuhiko » Tue, Apr 28, 2015, 2:33 PM UTC

vezzy-fnord wrote: post #105

the_mitsuhiko wrote: post #91

Earlier quoted context omitted.

> 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 obvio…

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.

Post by forgottenpass » Tue, Apr 28, 2015, 2:42 PM UTC

hp wrote: post #131

forgottenpass wrote: post #123

Earlier quoted context omitted.

This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. The worst part is that I sorta understand why some low-rent blogo-journolist pulls that nonsense. Hacker News should be better than this. A juicy pullquote can be an attractive headline and cheap and easy to write article. Start with a basic technical introduction paraphrasing wikipedia but doesn't get the reader anywhere…

I would call it "dbus performance overhead is userspace library AND context switching" See: http://article.gmane.org/gmane.linux.kernel/1939651 Or really, it isn't "context switching"; it's that there's the bus daemon in the middle which multiplies the userspace library overhead by 2, since messages are read and written twice as many times if you have the daemon in the middle. Speeding up read/parse and marshal/write…

Post by tormeh » Tue, Apr 28, 2015, 2:58 PM UTC

antocv wrote: post #127

tcfunk wrote: post #113

Earlier quoted context omitted.

Probably referring to the link title, which could imply quite a bit more than it simply being slow.

Well how can it be slow but not screwed up?

Post by vezzy-fnord » Tue, Apr 28, 2015, 3:02 PM UTC

thuffy wrote: post #136

vezzy-fnord wrote: post #132

Earlier quoted context omitted.

Moore's law makes it faster, but Wirth's law compensates for that dearly. Let's also not forget that pesky Amdahl making our bottlenecks stay bottlenecks, as some things are just fundamentally wrong for performance.

Kinda good points; however: Wirth's law is more true for commercial software where profit is the motive. Amdahl's law only really makes sense in parallel computing. All that is beside the real point; which is that in this post-Snowden world, we should not be sacrificing security for performance.

Post by vezzy-fnord » Tue, Apr 28, 2015, 3:05 PM UTC

the_mitsuhiko wrote: post #141

vezzy-fnord wrote: post #105

Earlier quoted context omitted.

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.