"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?
I'm particularly curious after reading the comments on LWN [lwn.net], and specifically this [lwn.net]:
Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the
I love how they blast Google for not being willing to meet halfway, but they're doing exactly the same thing.
Not that there's actually anything wrong with -either- side, but if you're going to redress someone for something, you should make sure you're not guilty of it yourself first.
Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again? Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is co
by Anonymous Coward writes:
on Thursday February 04, 2010 @05:29AM (#31020144)
I'm commenting anonymously because I'm closely involved with Android. I'm not going to comment on whether wakelocks are good or bad.
But mjg59's comment about ARM retention state being as good as suspend is blatantly wrong at a SoC level. There are several good reasons why a suspend details is better than retention but I can't go into the details due to NDAs. But I can vouch that I have personally seen power usage shoot up on well known Android phones when suspend is disabled and only retention is done.
So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.
Just to make my stance clear, I'm all for having the Android kernel merged into mainline.
Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.
Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.
So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.
I have worked on embedded devices - Linux based and others - for over a decade, and mjg59 is right. If you need something as brutal as hard suspend mode, you're doing it wrong. Any serious low power optimized ARM SoC can run down to very low current when idle, and has peripherals which can be individually clocked down and/or gated. I did work in a periphery way on the G1 at Google, and was very surprised at the way power gating was done. Put simply: the only other embedded OS in the same class as Android which does power gating like this is Windows Mobile. Everyone else learned it was unnecessary a long time ago. I was fairly shocked how few engineers had ever done serious embedded work before, and the result shows.
I know the Qualcomm parts have horrendously stupid design decisions in them which prevent decent idle current, but it's a wash compared to the other sources of battery drain. It's also a wash compared to the damage it does to your code design to support full suspend as part of normal per-second operation.
The Linux maintainers are right: Android is just doing it the wrong way. If there's any one feature I think Android could have done without, it's wake-locks. Learn how to use fine-grained clock switching and gating, not brutally-coarse-grained suspend. This isn't a bloody laptop. And no, I'm not saying this as a back seat driver: I really have done this kind of crap for a decade.
Technical aspects (Score:5, Informative)
"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?
I'm particularly curious after reading the comments on LWN [lwn.net], and specifically this [lwn.net]:
Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the
Re: (Score:2, Insightful)
I love how they blast Google for not being willing to meet halfway, but they're doing exactly the same thing.
Not that there's actually anything wrong with -either- side, but if you're going to redress someone for something, you should make sure you're not guilty of it yourself first.
Re: (Score:5, Informative)
Some background on this:
Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again?
Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is co
Re:Technical aspects (Score:5, Interesting)
I'm commenting anonymously because I'm closely involved with Android. I'm not going to comment on whether wakelocks are good or bad.
But mjg59's comment about ARM retention state being as good as suspend is blatantly wrong at a SoC level. There are several good reasons why a suspend details is better than retention but I can't go into the details due to NDAs. But I can vouch that I have personally seen power usage shoot up on well known Android phones when suspend is disabled and only retention is done.
So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.
Just to make my stance clear, I'm all for having the Android kernel merged into mainline.
Re:Technical aspects (Score:4, Interesting)
Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.
Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.
Re:Technical aspects (Score:5, Interesting)
So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.
I have worked on embedded devices - Linux based and others - for over a decade, and mjg59 is right. If you need something as brutal as hard suspend mode, you're doing it wrong. Any serious low power optimized ARM SoC can run down to very low current when idle, and has peripherals which can be individually clocked down and/or gated. I did work in a periphery way on the G1 at Google, and was very surprised at the way power gating was done. Put simply: the only other embedded OS in the same class as Android which does power gating like this is Windows Mobile. Everyone else learned it was unnecessary a long time ago. I was fairly shocked how few engineers had ever done serious embedded work before, and the result shows.
I know the Qualcomm parts have horrendously stupid design decisions in them which prevent decent idle current, but it's a wash compared to the other sources of battery drain. It's also a wash compared to the damage it does to your code design to support full suspend as part of normal per-second operation.
The Linux maintainers are right: Android is just doing it the wrong way. If there's any one feature I think Android could have done without, it's wake-locks. Learn how to use fine-grained clock switching and gating, not brutally-coarse-grained suspend. This isn't a bloody laptop. And no, I'm not saying this as a back seat driver: I really have done this kind of crap for a decade.