5 ms·
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 networ
by 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 agoYou’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 agoMy 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 agohttp://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 agoI 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 agoYou 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 agoNo 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 agoDid 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.