5 ms·

The announcement email from David Herrmann explains that they did consider a user-space implementation, and lists the reasons why they decided that it had to be

by sjellis 10y ago

The announcement email from David Herrmann explains that they did consider a user-space implementation, and lists the reasons why they decided that it had to be in-kernel: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/003047.html https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...

qwertyuiop924 10y ago
I was talking about KDbus, the predecessor to this.
saynsedit 10y ago
The reasons are mostly performance reasons. As I said in my other post, IPC latency is way down in the priority list of things to optimize (relatively to network and disk latency). Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.
- deno 10y ago
  You’re ignoring the fact that Bus1 is based on binder, not dbus, so performance (mostly power efficiency) apparently was an issue—on Android. So now you have two ends of the spectrum where this effort does matter, performance wise. This only leaves the middle (desktop), but there are other reasons why that evil desktop crowd wants IPC in kernel, however high on a ‘priority list’ they might be.
  - saynsedit 10y ago
    My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent. You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.
    - deno 10y ago
      http://lwn.net/Articles/504984/ http://lwn.net/Articles/504984/ #Priority Inversion #Latency It’s not about tight loops. Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.
      - deleted 10y ago
        [deleted]
      - saynsedit 10y ago
        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.
gpderetta 10y ago
> o guarantee a global message order [...] > o scale with the number of CPUs available [...] It seems to me that these two goals are conflicting. If they give up the first goal then suddenly the need of a broker disappear. edit: quoting from the message linked by parent. edit2: by reading the description of the ordering guarantees, it seems that they actually only guarantee partial ordering.
- tomegun 10y ago
  One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-ordering https://github.com/bus1/bus1/wiki/Message-ordering
  - gpderetta 10y ago
    As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.
    - tomegun 10y ago
      I don't see how. We should handle side-channel communication just fine. Care to give an example?
      - gpderetta 10y ago
        proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2; There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.

by sjellis 10y ago

qwertyuiop924 10y ago

I was talking about KDbus, the predecessor to this.

saynsedit 10y ago

The reasons are mostly performance reasons. As I said in my other post, IPC latency is way down in the priority list of things to optimize (relatively to network and disk latency). Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.

deno 10y ago
You’re ignoring the fact that Bus1 is based on binder, not dbus, so performance (mostly power efficiency) apparently was an issue—on Android. So now you have two ends of the spectrum where this effort does matter, performance wise. This only leaves the middle (desktop), but there are other reasons why that evil desktop crowd wants IPC in kernel, however high on a ‘priority list’ they might be.
- saynsedit 10y ago
  My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent. You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.
  - deno 10y ago
    http://lwn.net/Articles/504984/ http://lwn.net/Articles/504984/ #Priority Inversion #Latency It’s not about tight loops. Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.
    - deleted 10y ago
      [deleted]
    - saynsedit 10y ago
      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.

gpderetta 10y ago

> o guarantee a global message order [...] > o scale with the number of CPUs available [...] It seems to me that these two goals are conflicting. If they give up the first goal then suddenly the need of a broker disappear. edit: quoting from the message linked by parent. edit2: by reading the description of the ordering guarantees, it seems that they actually only guarantee partial ordering.

tomegun 10y ago
One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-ordering https://github.com/bus1/bus1/wiki/Message-ordering
- gpderetta 10y ago
  As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.
  - tomegun 10y ago
    I don't see how. We should handle side-channel communication just fine. Care to give an example?
    - gpderetta 10y ago
      proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2; There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.