On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <[email protected]> wrote:
> On Mon, 31 May 2010, James Bottomley wrote:
>>
>> For MSM hardware, it looks possible to unify the S and C states by doing
>> suspend to ram from idle but I'm not sure how much work that is.
>
> On ARM, it's not rocket science and we have in tree support for this
> already (OMAP). I have done the same thing on a Samsung part as a
> prove of concept two years ago and it's really easy as the hardware is
> sane. Hint: It's designed for mobile devices :)
>
We already enter the same power state from idle and suspend on msm. In
the absence of misbehaving apps, the difference in power consumption
is entirely caused by periodic timers in the user-space framework
_and_ kernel. It only takes a few timers triggering per second (I
think 3 if they do no work) to double the average power consumption on
the G1 if the radio is off. We originally added wakelocks because the
hardware we had at the time had much lower power consumption in
suspend then idle, but we still use suspend because it saves power.
--
Arve Hj?nnev?g
On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <[email protected]> wrote:
> > On Mon, 31 May 2010, James Bottomley wrote:
> >>
> >> For MSM hardware, it looks possible to unify the S and C states by doing
> >> suspend to ram from idle but I'm not sure how much work that is.
> >
> > On ARM, it's not rocket science and we have in tree support for this
> > already (OMAP). I have done the same thing on a Samsung part as a
> > prove of concept two years ago and it's really easy as the hardware is
> > sane. Hint: It's designed for mobile devices :)
> >
>
> We already enter the same power state from idle and suspend on msm. In
> the absence of misbehaving apps, the difference in power consumption
> is entirely caused by periodic timers in the user-space framework
> _and_ kernel. It only takes a few timers triggering per second (I
> think 3 if they do no work) to double the average power consumption on
> the G1 if the radio is off. We originally added wakelocks because the
> hardware we had at the time had much lower power consumption in
> suspend then idle, but we still use suspend because it saves power.
So how do you differentiate between timers which _should_ fire and
those you do not care about ?
We have mechanisms in place to defer timers so the wakeups are
minimized. If that's not enough we need to revisit.
Thanks,
tglx
2010/6/1 Thomas Gleixner <[email protected]>:
>
> On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
>
>> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <[email protected]> wrote:
>> > On Mon, 31 May 2010, James Bottomley wrote:
>> >>
>> >> For MSM hardware, it looks possible to unify the S and C states by doing
>> >> suspend to ram from idle but I'm not sure how much work that is.
>> >
>> > On ARM, it's not rocket science and we have in tree support for this
>> > already (OMAP). I have done the same thing on a Samsung part as a
>> > prove of concept two years ago and it's really easy as the hardware is
>> > sane. Hint: It's designed for mobile devices :)
>> >
>>
>> We already enter the same power state from idle and suspend on msm. In
>> the absence of misbehaving apps, the difference in power consumption
>> is entirely caused by periodic timers in the user-space framework
>> _and_ kernel. It only takes a few timers triggering per second (I
>> think 3 if they do no work) to double the average power consumption on
>> the G1 if the radio is off. We originally added wakelocks because the
>> hardware we had at the time had much lower power consumption in
>> suspend then idle, but we still use suspend because it saves power.
>
> So how do you differentiate between timers which _should_ fire and
> those you do not care about ?
>
Only alarms are allowed to fire while suspended.
> We have mechanisms in place to defer timers so the wakeups are
> minimized. If that's not enough we need to revisit.
>
Deferring the the timers forever without stopping the clock can cause
problems. Our user space code has a lot of timeouts that will trigger
an error if an app does not respond in time. Freezing everything and
stopping the clock while suspended is a lot simpler than trying to
stop individual timers and processes from running.
--
Arve Hj?nnev?g
On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
> 2010/6/1 Thomas Gleixner <[email protected]>:
> >
> > On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
> >
> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <[email protected]> wrote:
> >> > On Mon, 31 May 2010, James Bottomley wrote:
> >> >>
> >> >> For MSM hardware, it looks possible to unify the S and C states by doing
> >> >> suspend to ram from idle but I'm not sure how much work that is.
> >> >
> >> > On ARM, it's not rocket science and we have in tree support for this
> >> > already (OMAP). I have done the same thing on a Samsung part as a
> >> > prove of concept two years ago and it's really easy as the hardware is
> >> > sane. Hint: It's designed for mobile devices :)
> >> >
> >>
> >> We already enter the same power state from idle and suspend on msm. In
> >> the absence of misbehaving apps, the difference in power consumption
> >> is entirely caused by periodic timers in the user-space framework
> >> _and_ kernel. It only takes a few timers triggering per second (I
> >> think 3 if they do no work) to double the average power consumption on
> >> the G1 if the radio is off. We originally added wakelocks because the
> >> hardware we had at the time had much lower power consumption in
> >> suspend then idle, but we still use suspend because it saves power.
> >
> > So how do you differentiate between timers which _should_ fire and
> > those you do not care about ?
> >
>
> Only alarms are allowed to fire while suspended.
>
> > We have mechanisms in place to defer timers so the wakeups are
> > minimized. If that's not enough we need to revisit.
> >
>
> Deferring the the timers forever without stopping the clock can cause
> problems. Our user space code has a lot of timeouts that will trigger
> an error if an app does not respond in time. Freezing everything and
> stopping the clock while suspended is a lot simpler than trying to
> stop individual timers and processes from running.
And resume updates timekeeping to account for the slept time. So the
only way to get away with that is to sleep under a second or just
ignoring the update by avoiding the access to rtc.
So how do you keep timekeeping happy ?
Thanks,
tglx
2010/6/2 Thomas Gleixner <[email protected]>:
> On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
>> 2010/6/1 Thomas Gleixner <[email protected]>:
>> >
>> > On Mon, 31 May 2010, Arve Hj?nnev?g wrote:
>> >
>> >> On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner <[email protected]> wrote:
>> >> > On Mon, 31 May 2010, James Bottomley wrote:
>> >> >>
>> >> >> For MSM hardware, it looks possible to unify the S and C states by doing
>> >> >> suspend to ram from idle but I'm not sure how much work that is.
>> >> >
>> >> > On ARM, it's not rocket science and we have in tree support for this
>> >> > already (OMAP). I have done the same thing on a Samsung part as a
>> >> > prove of concept two years ago and it's really easy as the hardware is
>> >> > sane. Hint: It's designed for mobile devices :)
>> >> >
>> >>
>> >> We already enter the same power state from idle and suspend on msm. In
>> >> the absence of misbehaving apps, the difference in power consumption
>> >> is entirely caused by periodic timers in the user-space framework
>> >> _and_ kernel. It only takes a few timers triggering per second (I
>> >> think 3 if they do no work) to double the average power consumption on
>> >> the G1 if the radio is off. We originally added wakelocks because the
>> >> hardware we had at the time had much lower power consumption in
>> >> suspend then idle, but we still use suspend because it saves power.
>> >
>> > So how do you differentiate between timers which _should_ fire and
>> > those you do not care about ?
>> >
>>
>> Only alarms are allowed to fire while suspended.
>>
>> > We have mechanisms in place to defer timers so the wakeups are
>> > minimized. If that's not enough we need to revisit.
>> >
>>
>> Deferring the the timers forever without stopping the clock can cause
>> problems. Our user space code has a lot of timeouts that will trigger
>> an error if an app does not respond in time. Freezing everything and
>> stopping the clock while suspended is a lot simpler than trying to
>> stop individual timers and processes from running.
>
> And resume updates timekeeping to account for the slept time. So the
No, for the monotonic clock it does the opposite. The hardware clock
is read on resume and the offset is set so the monotonic clock gets
the same value as it had when suspend was called.
> only way to get away with that is to sleep under a second or just
> ignoring the update by avoiding the access to rtc.
>
> So how do you keep timekeeping happy ?
>
--
Arve Hj?nnev?g
On Wed, 2 Jun 2010, Arve Hj?nnev?g wrote:
> 2010/6/2 Thomas Gleixner <[email protected]>:
> > On Tue, 1 Jun 2010, Arve Hj?nnev?g wrote:
> >> Deferring the the timers forever without stopping the clock can cause
> >> problems. Our user space code has a lot of timeouts that will trigger
> >> an error if an app does not respond in time. Freezing everything and
> >> stopping the clock while suspended is a lot simpler than trying to
> >> stop individual timers and processes from running.
> >
> > And resume updates timekeeping to account for the slept time. So the
>
> No, for the monotonic clock it does the opposite. The hardware clock
> is read on resume and the offset is set so the monotonic clock gets
> the same value as it had when suspend was called.
Grr, yes. Misread the code. -ENOTENOUGHCOFFEE
Thanks,
tglx