Comment by saynsedit | Hacker News Reader

Comment by saynsedit | Hacker News Reader

Parent Full thread

* I don't see a time-slice accounting for the bus broker as an issue. If it's a system daemon, you can define away the problem. What's the use case for doing time-slice accounting where ignoring the system daemon's usage matters?

* for priority inheritance, have multiple daemons for each message priority level. Only privileges processes can use the high-priority message router, but can optionally use the low-priority message router when they want to inherit the priority of their sender.

* like I said, context switching is irrelevant since context switching is not the bottleneck in event latency nor in power usage.

* if FD accounting is important, move it out of the broker and make it p2p with broker coordination.

* kernel and LSM hooking feels like a feature looking for a use-case. If anyone really wants to do that, I'm sure the specific use case can be accommodated. Not every user space program need be trackable via LSM.

* for side channel and message ordering, why is this a core feature of the transport layer? I don't think all applications need this and if they do, something simpler and more specific to the application protocol could be developed. Generalized message ordering guarantees as part of the transport layer seems like it violates end-to-end design. A robust application protocol will end up ensuring this on its own anyway.

There you have it. I'm sorry but you don't have a strong case. Linus is even more opposed to this than I am and is probably better about system design than I am as well.

I don't get what you are trying to achieve with this discussion. You didn't provide any serious alternative, you just say that the issues don't matter to you.

Obviously, if you do not care about any of the features, then you should not be using bus1. But that does not mean that others don't care, so why are you objecting so strongly to us providing a solution to these problems?

Firstly, if you don't want a bus IPC with multicast messaging, then use something else. But if you DO want that, then you cannot ignore message ordering, that is the whole point (otherwise you could just use repeated unicast instead).

If you want message ordering you cannot split things into several daemons, or you break the order (unless you add some more communication on top). Same with p2p (side-channel) communication for FDs.

The broker is basically doing work on behalf of the sender, but without proper time-slice accounting it is not accounted accordingly. Obviously in many cases that does not matter, but you cannot simply ignore the problem if you want a general, lasting solution.

It is true that performance is not the main feature, but that is not to say that it does not matter at all (to anyone, ever), so you cannot simply brush it aside, proposing a solution that would have (almost by definition) hundreds of percent worse performance (as you are just doing more round-trips, even ignoring the context switching). To say that IPC latency is "not the bottle neck" only makes sense if you have a specific use-case in mind. With sufficiently low latency, we open up the possibility of using IPC for things that could only be done in-process today. This is not the MAIN purpose, but ignoring it is short-sighted.

I just got an email today from people asking about the LSM hooks, so there certainly is interest, and this (like the message order) is not something you can bolt on top.

I have not seen Linus comment on this, please give a link if you have. Whatever reservations he had about kdbus should not apply to bus1.

Look, there are plenty of things that could be improved on bus1, and I'm sure some careful review will find things we could and should do differently, but please at least spend more than five seconds looking into what we did and thinking about the problem. We want a multicast IPC system, but we want one done properly. You cannot simply say that doing one that is several times slower, doesn't do proper resource accounting, gets the message order wrong and cannot integrate with LSM is "good enough for me" and expect that to be the end of it.

The original point is that this doesn't have to be a kernel. None of the current rationale gives any use-cases for the features you're offering, you're just saying "this feature requires kernel support" well what is the use case for that feature? Maybe there is another way that doesn't require kernel support.

Multicast messaging as your main motivation for a message ordering layer when that layer has drastic effects on performance and operational characteristics is a strange proposition. I'm willing to argue that 99% of application protocols will have no use for baked-in multicast as you've implemented it. What exactly is the killer use case for multicast messaging with side-channel aware causal message ordering? What prevents an application that cares about this from ordering incoming messages according to a lamport clock itself?

I see no downside to these features in general, it's just that the justification for putting it in the kernel is weak. Kernel code has an infinitely high maintenance cost and it's not clear bus1 is the end-all messaging layer you want it to be. There are lots of past failed examples, inotify, dnotify, and fanotify come to mind...

Reply on news.ycombinator.com