4 ms·

I don't buy these arguments... For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to ha

I don't buy these arguments... For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to have two message routing processes, one for low priority messages and one for high priority messages. As far as 4 context switches versus 2 with regards to latency. A context switch takes microseconds... This is vastly smaller than the 250ms UI response time. Again, this looks like a solution looking for a problem. Fixing wifi or screen before working on micro-problems in the kernel for the sake of global power efficiency is founded in every kind of logic. It's literally Amdahl's Law: reducing power usage in a component that already has the most minimal power usage is a waste of effort for no noticeable effect. The cost-benefit ratio is indefensible. This is insanity.

deno 10y ago
You seem to be fixated on this idea that this is purely a performance optimization. You’ve made it your strawman. But that is in fact only one minor point. Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.
- saynsedit 10y ago
  No I very much did not make it my strawman. Look at the original announcement email, they themselves list performance as their main motivation. Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument. The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.
  - tomegun 10y ago
    Did you read the ksummit email? There were eight reasons given, performance was one of them (the third one). Not the only one. Not the main one.
    - saynsedit 10y ago
      What would you say is the main driving rationale for bus1?
      - tomegun 10y ago
        I would say it is to create the primitives needed for a multicast-capable (n-to-n) local IPC system. Obviously in such a way that it is safe, reliable, predictable, scalable, fast and lightweight.
        saynsedit 10y ago
        You can create a multicast-capable (n-to-n) IPC system in such a way that is safe, reliable, predictable, scalable, fast and lightweight in user-space. Kernel is not required!
        tomegun 10y ago
        How? We give a list of issues in the email.
        saynsedit 10y ago
        * 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.
  - qwertyuiop924 10y ago
    >The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort. Finally, He said what we're all thinking!

deno 10y ago

You seem to be fixated on this idea that this is purely a performance optimization. You’ve made it your strawman. But that is in fact only one minor point. Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.

saynsedit 10y ago
No I very much did not make it my strawman. Look at the original announcement email, they themselves list performance as their main motivation. Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument. The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.
- tomegun 10y ago
  Did you read the ksummit email? There were eight reasons given, performance was one of them (the third one). Not the only one. Not the main one.
  - saynsedit 10y ago
    What would you say is the main driving rationale for bus1?
    - tomegun 10y ago
      I would say it is to create the primitives needed for a multicast-capable (n-to-n) local IPC system. Obviously in such a way that it is safe, reliable, predictable, scalable, fast and lightweight.
      - saynsedit 10y ago
        You can create a multicast-capable (n-to-n) IPC system in such a way that is safe, reliable, predictable, scalable, fast and lightweight in user-space. Kernel is not required!
        tomegun 10y ago
        How? We give a list of issues in the email.
        saynsedit 10y ago
        * 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.
- qwertyuiop924 10y ago
  >The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort. Finally, He said what we're all thinking!