4 ms·
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, o
by 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 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.