From: Arve Hjønnevåg on
2010/8/3 <david(a)lang.hm>:
> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>
>> 2010/8/3 �<david(a)lang.hm>:
>>>
>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>
>>>> On Tue, Aug 3, 2010 at 5:51 PM, �<david(a)lang.hm> wrote:
>>>>>
>>>>> On Tue, 3 Aug 2010, Paul E. McKenney wrote:
>>>>>
>>>>>> OK, I'll bite...
>>>>>
>>>>> thanks, this is not intended to be a trap.
>>>>>
>>>>>> From an Android perspective, the differences are as follows:
>>>>>>
>>>>>> 1. ? ? ?Deep idle states are entered only if there are no runnable
>>>>>> tasks.
>>>>>> ? ? ? ?In contrast, opportunistic suspend can happen even when there
>>>>>> ? ? ? ?are tasks that are ready, willing, and able to run.
>>>>>
>>>>> Ok, this is a complication to what I'm proposing (and seems a little
>>>>> odd,
>>>>> but I can see how it can work), but not neccessarily a major problem.
>>>>> it
>>>>> depends on exactly how the decision is made to go into low power states
>>>>> and/or suspend. If this is done by an application that is able to look
>>>>> at
>>>>> either all activity or ignore one cgroup of processes at different
>>>>> times
>>>>> in
>>>>> it's calculations than this would work.
>>>>>
>>>>>> 2. ? ? ?There can be a set of input events that do not bring the
>>>>>> system
>>>>>> ? ? ? ?out of suspend, but which would bring the system out of a deep
>>>>>> ? ? ? ?idle state. ?For example, I believe that it was stated that one
>>>>>> ? ? ? ?of the Android-based smartphones ignores touchscreen input
>>>>>> while
>>>>>> ? ? ? ?suspended, but pays attention to it while in deep idle states.
>>>>>
>>>>> I see this as simply being a matter of what devices are still enabled
>>>>> at
>>>>> the
>>>>> different power savings levels. At one level the touchscreen is still
>>>>> powered, while at another level it isn't, and at yet another level you
>>>>> have
>>>>> to hit the power soft-button. This isn't fundamentally different from
>>>>> powering off a USB peripheral that the system decides is idle (and then
>>>>> not
>>>>> seeing input from it until something else wakes the system)
>>>>
>>>> The touchscreen on android devices is powered down long before we
>>>> suspend, so that is not a good example. There is still a significant
>>>> difference between suspend and idle though. In idle all interrupts
>>>> work, in suspend only interrupts that the driver has called
>>>> enable_irq_wake on will work (on platforms that support it).
>>>
>>> are you talking about Android here or are you talking genricly across all
>>> platforms?
>>>
>>
>> This appears to be the current Linux driver model. Old platform code
>> hardcoded the wakeup interrupts.
>
> not quite the question I was trying (and failing) to ask, but from the
> answer it sounds like setting suspend to wake up on all interrupts is the
> same as idle.
>

No, suspend does a lot more than idle.

> so here suspend is looking like just a variation of low-power idle
> (different wakeup criteria)
>
>>>>>> 3. ? ? ?The system comes out of a deep idle state when a timer
>>>>>> ? ? ? ?expires. ?In contrast, timers cannot expire while the
>>>>>> ? ? ? ?system is suspended. ?(This one is debatable: some people
>>>>>> ? ? ? ?argue that timers are subject to jitter, and the suspend
>>>>>> ? ? ? ?case for timers is the same as that for deep idle states,
>>>>>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
>>>>>> ? ? ? ?resulting discussions have produced much heat, but little
>>>>>> ? ? ? ?light. ?Such is life.)
>>>>>
>>>>> if you have the ability to wake for an alarm, you have the ability to
>>>>> wake
>>>>> for a timer (if from no other method than to set the alarm to when the
>>>>> timer
>>>>> tick would go off)
>>>>>
>>>>
>>>> If you just program the alarm you will wake up see that the monotonic
>>>> clock has not advanced and set the alarm another n seconds into the
>>>> future. Or are proposing that suspend should be changed to keep the
>>>> monotonic clock running? If you are, why? We can enter the same
>>>> hardware states from idle, and modifying suspend to wake up more often
>>>> would increase the average power consumption in suspend, not improve
>>>> it for idle. In other words, if suspend wakes up as often as idle, why
>>>> use suspend?
>>>
>>> no, I was thinking that you set the alarm to go off, and when it goes off
>>> and wakes you up, you correct other local clocks before doing anything
>>> else.
>>>
>>> even if they wake up at the same time, you would use suspend instead of
>>> idle
>>> if it saved more power (allowing for the power to get in and out of
>>> suspend
>>> vs the power to get in and out of idle)
>>
>> Suspend and idle use the same power state on the devices we shipped.
>> The power saving we get from suspend if from ignoring the timers.
>
> Ok, so if you set the alarm to the next time the timer for a privilaged task
> would run and wake up then to be completely transparent to the privilaged
> task, or you could decide to disable the timers as well
>
> again, this looks like suspend and idle are very closely related.
>
>>> in this case, another reason you would consider using suspend over idle
>>> is
>>> that you can suspend until the next timer that your privilaged
>>> applications
>>> have set, and skip timers set by the non-privilaged applications,
>>> resulting
>>> in more time asleep.
>>
>> Without wakelock or suspend blockers this can still break since a
>> privileged application may be waiting on a resource held by a
>> non-privileged application.
>
> since the non-privilaged application is never frozen when a privilaged
> application is running, I'm not sure how you would get this to happen that
> wouldn't also be a problem with wakelocks.

With wakelocks we annotate that we have important work to do, until
that work is accomplished we do not suspend. If you modify the idle
code ignore some processes' timers the system may get stuck in idle
while waiting for a non-privileged application to release a resource.

>
> if you want to have a privilaged application keep the system awake while it
> waits for a non-privilaged application, all it would need to do is to set a
> timer near enough in the future that it's considered 'awake' all the time.
> this will cost a context switch every timeout period (for the application to
> check that it's still waiting and set the next timer), but that's pretty
> cheap.

No, this will kill your idle power.

>
> one thing this would destroy is the stats currently built around the
> wakelock, but since they would be replaced by stats of exactly the type of
> thing that powertop was written to deal with, I don't see this as a problem
> (powertop would just have to learn a mode where it ignores the
> non-privilaged tasks).consolodating tools is a good thing.
>
>>>>>> There may well be others.
>>>>>>
>>>>>> Whether these distinctions are a good thing or a bad thing is one of
>>>>>> the topics of this discussion. ?But the distinctions themselves are
>>>>>> certainly very real, from what I can see.
>>>>>>
>>>>>> Or am I missing your point?
>>>>>
>>>>> these big distinction that I see as significant seem to be in the
>>>>> decision
>>>>> of when to go into the different states, and the difference between the
>>>>> states ?themselves seem to be less significant (and either very close
>>>>> to,
>>>>> or
>>>>> within the variation that already exists for power saving modes)
>>>>>
>>>>> If I'm right bout this, then it would seem to simplify the concept and
>>>>> change it from some really foreign android-only thing into a special
>>>>> case
>>>>> variation of existing core concepts.
>>>>
>>>> Suspend is not an android only concept. The android extensions just
>>>> allow us to aggressively use suspend without loosing (or delaying)
>>>> wakeup events. On the hardware that we shipped we can enter the same
>>>> power mode from idle as we do in suspend, but we still use suspend
>>>> primarily because it stops the monotonic clock and all the timers that
>>>> use it. Changing suspend to behave more like an idle mode, which seems
>>>> to be what you are suggesting, would not buy us anything.
>>>
>>> Ok, If I am understanding you correctly I think this is an important
>>> point.
>>>
>>> What Android calls suspend is not what other linux distros call suspend,
>>> it's just a low-power mode with different wakeup rules.
>>>
>>> Is this correct?
>>>
>>
>> No. Android suspend is Linux suspend. We just enter it more frequently.
>
> In Linux, a full suspend normally takes the system down to a mode that can't
> be reached by the normal idle mechnism (including powering down
> peripherals). It also takes significantly different actions to wake up. What
> you are describing seems much milder than that.

We use the normal suspend sequence. The shipping hardware we have just
don't need to do lot

>
>>> If this is the case it seems even more so that the android suspend should
>>> be
>>> addressed by tieing into the power management/idle stuff rather than the
>>> suspend/hibernate side of things
>>>
>>> is the reason you want to stop the onotonic clock and the timers because
>>> the
>>> applications need to be fooled into thinking no time has passed?
>>>
>>
>> Yes, but this is not an Android extension, it is part of the normal
>> Linux suspend sequence.
>
> no, as noted by others in this thread, normal linux suspend/resume modifies
> the clock to show that time has passed since the suspend happened.
>

The monotonic clock always stops. There are a few different ways to
maintain the realtime clock and we use one of them.

>>> or is it to prevent extranious wakeups?
>>>
>> That too.
>
> as noted above, this sounds like it's configurable.
>
>>> or is it to save additional power?
>>>
>> No (assuming you are asking about the clock), the actual hardware
>> clock (on msm) stops even in idle but it is resynchronized on wakeup
>> with a clock that never stops when used from idle.
>
> so I'm left not understanding the huge desire to stop the monotonic clock.
>

If you ignore the timers and don't stop the clock they are based on,
you break a lot of apps when you resume (watchdogs and timeouts
trigger). If you don't ignore timers, you can't sleep very long with
existing software.

>>>>> you have many different power saving modes, the daemon (or kernel code)
>>>>> that
>>>>> is determining which mode to go into would need different logic
>>>>> (including,
>>>>> but not limited to the ability to be able to ignore one or more cgroups
>>>>> of
>>>>> processes). different power saving modes have different trade-offs, and
>>>>> some
>>>>> of them power down different peripherals (which is always a platform
>>>>> specific, if not system specific set of trade-offs)
>>>>>
>>>>
>>>> The hardware specific idle hook can (and does) decide to go into any
>>>> power state from idle that does not disrupt any active devices.
>>>
>>> This I know is an Andoid specific thing. On other platforms power states
>>> very definantly can make user visible changes.
>>
>> How is this Android specific?
>
> you are stating that this must be suspend because low-power idle must be
> transparent to the user.

It must be transparent to the rest of the system.

>
> I am saying that on Linux, low-power idle commonly is not transparent to the
> user, so the requirement for it to be transparent (therefor putting the
> suspend into a different category) is an Android only requirement.
>

I'm am not talking about minor latencies. If you have a platform that
for instance turns off you screen dma when entering idle, it is broken
whether is running Android or not. If it does the same in suspend it
is not a problem.

--
Arve Hj�nnev�g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on
On Wed, 4 Aug 2010 00:10:21 -0700
Arve Hj�nnev�g <arve(a)android.com> wrote:

> >
> > you are stating that this must be suspend because low-power idle must be
> > transparent to the user.
>
> It must be transparent to the rest of the system.

Perhaps transparent is badly worded. Both suspend and idle are in some
way "transparent". Idle doesnt happen when an application is runnable.
Suspend is transparent in that the application can not easily detect if
it happened.

Cheers,
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: david on
On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:

> 2010/8/3 <david(a)lang.hm>:
>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> 2010/8/3 �<david(a)lang.hm>:
>>>>
>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>> in this case, another reason you would consider using suspend over idle
>>>> is
>>>> that you can suspend until the next timer that your privilaged
>>>> applications
>>>> have set, and skip timers set by the non-privilaged applications,
>>>> resulting
>>>> in more time asleep.
>>>
>>> Without wakelock or suspend blockers this can still break since a
>>> privileged application may be waiting on a resource held by a
>>> non-privileged application.
>>
>> since the non-privilaged application is never frozen when a privilaged
>> application is running, I'm not sure how you would get this to happen that
>> wouldn't also be a problem with wakelocks.
>
> With wakelocks we annotate that we have important work to do, until
> that work is accomplished we do not suspend. If you modify the idle
> code ignore some processes' timers the system may get stuck in idle
> while waiting for a non-privileged application to release a resource.

if you don't have a wakelock the system could go into suspend under the
exact same conditions. If the privilaged program wants to be sure of
preventing this, all it needs to do is to set of timer to take action
before the timeout.

>>
>> if you want to have a privilaged application keep the system awake while it
>> waits for a non-privilaged application, all it would need to do is to set a
>> timer near enough in the future that it's considered 'awake' all the time.
>> this will cost a context switch every timeout period (for the application to
>> check that it's still waiting and set the next timer), but that's pretty
>> cheap.
>
> No, this will kill your idle power.

you are only doing this every several seconds to prevent the system from
suspending.

it's possible that I'm making false assumptions about how quickly you want
to go into full suspend mode.

if a user is doing nothing that would warrent wakelocks, but has an
unprivilaged application running (a dancing cows game), and is doing
nothing other than occasionally hitting a button, how short is the timeout
that you would set that would have the system go into suspend? (i.e. how
frequently must the user do something to keep the system awake)

or let's use a better example, the user has an unprivilaged book-reader
application, how quickly must they change pages to prevent the system from
suspending?

I'm figuring that these times are in the 1-5 minute range.

therefor the timeout period I am mentioning above could easily be one
wakeup every 40-50 seconds.

that is not going to kill your idle power.

is my assumption about the length of the timeout incorrect?

>>
>> one thing this would destroy is the stats currently built around the
>> wakelock, but since they would be replaced by stats of exactly the type of
>> thing that powertop was written to deal with, I don't see this as a problem
>> (powertop would just have to learn a mode where it ignores the
>> non-privilaged tasks).consolodating tools is a good thing.
>>
>>>>>>> There may well be others.
>>>>>>>
>>>>>>> Whether these distinctions are a good thing or a bad thing is one of
>>>>>>> the topics of this discussion. ?But the distinctions themselves are
>>>>>>> certainly very real, from what I can see.
>>>>>>>
>>>>>>> Or am I missing your point?
>>>>>>
>>>>>> these big distinction that I see as significant seem to be in the
>>>>>> decision
>>>>>> of when to go into the different states, and the difference between the
>>>>>> states ?themselves seem to be less significant (and either very close
>>>>>> to,
>>>>>> or
>>>>>> within the variation that already exists for power saving modes)
>>>>>>
>>>>>> If I'm right bout this, then it would seem to simplify the concept and
>>>>>> change it from some really foreign android-only thing into a special
>>>>>> case
>>>>>> variation of existing core concepts.
>>>>>
>>>>> Suspend is not an android only concept. The android extensions just
>>>>> allow us to aggressively use suspend without loosing (or delaying)
>>>>> wakeup events. On the hardware that we shipped we can enter the same
>>>>> power mode from idle as we do in suspend, but we still use suspend
>>>>> primarily because it stops the monotonic clock and all the timers that
>>>>> use it. Changing suspend to behave more like an idle mode, which seems
>>>>> to be what you are suggesting, would not buy us anything.
>>>>
>>>> Ok, If I am understanding you correctly I think this is an important
>>>> point.
>>>>
>>>> What Android calls suspend is not what other linux distros call suspend,
>>>> it's just a low-power mode with different wakeup rules.
>>>>
>>>> Is this correct?
>>>>
>>>
>>> No. Android suspend is Linux suspend. We just enter it more frequently.
>>
>> In Linux, a full suspend normally takes the system down to a mode that can't
>> be reached by the normal idle mechnism (including powering down
>> peripherals). It also takes significantly different actions to wake up. What
>> you are describing seems much milder than that.
>
> We use the normal suspend sequence. The shipping hardware we have just
> don't need to do lot
>
>>
>>>> If this is the case it seems even more so that the android suspend should
>>>> be
>>>> addressed by tieing into the power management/idle stuff rather than the
>>>> suspend/hibernate side of things
>>>>
>>>> is the reason you want to stop the onotonic clock and the timers because
>>>> the
>>>> applications need to be fooled into thinking no time has passed?
>>>>
>>>
>>> Yes, but this is not an Android extension, it is part of the normal
>>> Linux suspend sequence.
>>
>> no, as noted by others in this thread, normal linux suspend/resume modifies
>> the clock to show that time has passed since the suspend happened.
>>
>
> The monotonic clock always stops. There are a few different ways to
> maintain the realtime clock and we use one of them.
>
>>>> or is it to prevent extranious wakeups?
>>>>
>>> That too.
>>
>> as noted above, this sounds like it's configurable.
>>
>>>> or is it to save additional power?
>>>>
>>> No (assuming you are asking about the clock), the actual hardware
>>> clock (on msm) stops even in idle but it is resynchronized on wakeup
>>> with a clock that never stops when used from idle.
>>
>> so I'm left not understanding the huge desire to stop the monotonic clock.
>>
>
> If you ignore the timers and don't stop the clock they are based on,
> you break a lot of apps when you resume (watchdogs and timeouts
> trigger). If you don't ignore timers, you can't sleep very long with
> existing software.

if you can stop the clocks they are based on, you could also shift them
into the future. but in any case, significant changes in time can cause
problems for suspended apps (if nothing else, broken network connections
because the machines elsewhere timed you out)

>>>>>> you have many different power saving modes, the daemon (or kernel code)
>>>>>> that
>>>>>> is determining which mode to go into would need different logic
>>>>>> (including,
>>>>>> but not limited to the ability to be able to ignore one or more cgroups
>>>>>> of
>>>>>> processes). different power saving modes have different trade-offs, and
>>>>>> some
>>>>>> of them power down different peripherals (which is always a platform
>>>>>> specific, if not system specific set of trade-offs)
>>>>>>
>>>>>
>>>>> The hardware specific idle hook can (and does) decide to go into any
>>>>> power state from idle that does not disrupt any active devices.
>>>>
>>>> This I know is an Andoid specific thing. On other platforms power states
>>>> very definantly can make user visible changes.
>>>
>>> How is this Android specific?
>>
>> you are stating that this must be suspend because low-power idle must be
>> transparent to the user.
>
> It must be transparent to the rest of the system.
>
>>
>> I am saying that on Linux, low-power idle commonly is not transparent to the
>> user, so the requirement for it to be transparent (therefor putting the
>> suspend into a different category) is an Android only requirement.
>>
>
> I'm am not talking about minor latencies. If you have a platform that
> for instance turns off you screen dma when entering idle, it is broken
> whether is running Android or not. If it does the same in suspend it
> is not a problem.

This isn't sounding quite right to me. I've seen too many discussions
about things like idle and USB devices/hubs/drives/etc getting powered
down for power savings modes to make me readily accept that everything
must be as transparent as you imply. Just the case of drive spin-down
shows that it's possible to do things that would be considered
destructive, but you have to have a flag and wake-up path to recover
within a 'reasonable' amount of time (I guess that this could be
'transparent' if that only implies that things must work eventually, which
isn't what I read into the statement)

David Lang
From: Rafael J. Wysocki on
On Wednesday, August 04, 2010, david(a)lang.hm wrote:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
> > 2010/8/3 <david(a)lang.hm>:
> >> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>> 2010/8/3 <david(a)lang.hm>:
> >>>>
> >>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
....
> >>>>> The hardware specific idle hook can (and does) decide to go into any
> >>>>> power state from idle that does not disrupt any active devices.
> >>>>
> >>>> This I know is an Andoid specific thing. On other platforms power states
> >>>> very definantly can make user visible changes.

It would be much better if you gave specific examples. Because, for instance,
I'm not sure what platforms you have in mind.

> >>> How is this Android specific?
> >>
> >> you are stating that this must be suspend because low-power idle must be
> >> transparent to the user.
> >
> > It must be transparent to the rest of the system.
> >
> >>
> >> I am saying that on Linux, low-power idle commonly is not transparent to the
> >> user, so the requirement for it to be transparent (therefor putting the
> >> suspend into a different category) is an Android only requirement.
> >>
> >
> > I'm am not talking about minor latencies. If you have a platform that
> > for instance turns off you screen dma when entering idle, it is broken
> > whether is running Android or not. If it does the same in suspend it
> > is not a problem.
>
> This isn't sounding quite right to me. I've seen too many discussions
> about things like idle and USB devices/hubs/drives/etc getting powered
> down for power savings modes to make me readily accept that everything
> must be as transparent as you imply. Just the case of drive spin-down
> shows that it's possible to do things that would be considered
> destructive, but you have to have a flag and wake-up path to recover
> within a 'reasonable' amount of time (I guess that this could be
> 'transparent' if that only implies that things must work eventually, which
> isn't what I read into the statement)

Well, consider a single character device and suppose there is an application
talking to the driver using read(), write(), ioctl(), whatever. Now suppose
you want to put the device into a low-power state such that the device can't
do the I/O in that state. You need to ensure that the app won't be able to
reach the device while in that state and you can (1) arrange things so that
the device is put into the full-power state whenever the app tries to access
it and (2) "freeze" the app so that it won't try to access the device being in
the low-power state.

Generally speaking (1) is what idle (and any other form of runtime PM) does and
(2) is what suspend does with respect to the whole system.

In the suspend case, when you have frozen all applications, you can
sequentially disable all interrupts except for a few selected ("wakeup") ones
in a safe way. By disabling them, you ensure that the CPU will only be
"revived" by a limited set of events and that allows the system to stay
low-power for extended time intervals.

To achieve the same result in the "idle" case, you'll need to have a mechanism
to disable interrupts (except for the "wakeup" ones) avoiding synchronization
problems (eg. situations in which task A, blocked on a "suspended" device
access, holds a mutex waited for by task B that needs to run so that we can
"suspend" another device). That, however, is a difficult problem.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on
On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj�nnev�g wrote:
> On Tue, Aug 3, 2010 at 5:51 PM, <david(a)lang.hm> wrote:
> > On Tue, 3 Aug 2010, Paul E. McKenney wrote:
> >
> >> On Tue, Aug 03, 2010 at 04:19:25PM -0700, david(a)lang.hm wrote:
> >>>
> >>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> >>>
> >>>> 2010/8/2 �<david(a)lang.hm>:
> >>>>>
> >>>>> so what is the fundamental difference between deciding to go into
> >>>>> low-power
> >>>>> idle modes to wake up back up on a given point in the future and
> >>>>> deciding
> >>>>> that you are going to be idle for so long that you may as well suspend
> >>>>> until
> >>>>> there is user input?
> >>>>>
> >>>>
> >>>> Low power idle modes are supposed to be transparent. Suspend stops the
> >>>> monotonic clock, ignores ready threads and switches over to a separate
> >>>> set of wakeup events/interrupts. We don't suspend until there is user
> >>>> input, we suspend until there is a wakeup event (user-input, incoming
> >>>> network data/phone-calls, alarms etc..).
> >>>
> >>> s/user input/wakeup event/ and my question still stands.
> >>>
> >>> low power modes are not transparent to the user in all cases (if the
> >>> screen backlight dimms/shuts off a user reading something will
> >>> notice, if the system switches to a lower clock speed it can impact
> >>> user response time, etc) The system is making it's best guess as to
> >>> how to best srve the user by sacraficing some capibilities to save
> >>> power now so that the power can be available later.
> >>>
> >>> as I see it, suspending until a wakeup event (button press, incoming
> >>> call, alarm, etc) is just another datapoint along the same path.
> >>>
> >>> If the system could not wake itself up to respond to user input,
> >>> phone call, alarm, etc and needed the power button pressed to wake
> >>> up (or shut down to the point where the battery could be removed and
> >>> reinstalled a long time later), I would see things moving into a
> >>> different category, but as long as the system has the ability to
> >>> wake itself up later (and is still consuming power) I see the
> >>> suspend as being in the same category as the other low-power modes
> >>> (it's just more expensive to go in and out of)
> >>>
> >>>
> >>> why should the suspend be put into a different category from the
> >>> other low-power states?
> >>
> >> OK, I'll bite...
> >
> > thanks, this is not intended to be a trap.
> >
> >> From an Android perspective, the differences are as follows:
> >>
> >> 1. � � �Deep idle states are entered only if there are no runnable tasks.
> >> � � � �In contrast, opportunistic suspend can happen even when there
> >> � � � �are tasks that are ready, willing, and able to run.
> >
> > Ok, this is a complication to what I'm proposing (and seems a little odd,
> > but I can see how it can work), but not neccessarily a major problem. it
> > depends on exactly how the decision is made to go into low power states
> > and/or suspend. If this is done by an application that is able to look at
> > either all activity or ignore one cgroup of processes at different times in
> > it's calculations than this would work.
> >
> >> 2. � � �There can be a set of input events that do not bring the system
> >> � � � �out of suspend, but which would bring the system out of a deep
> >> � � � �idle state. �For example, I believe that it was stated that one
> >> � � � �of the Android-based smartphones ignores touchscreen input while
> >> � � � �suspended, but pays attention to it while in deep idle states.
> >
> > I see this as simply being a matter of what devices are still enabled at the
> > different power savings levels. At one level the touchscreen is still
> > powered, while at another level it isn't, and at yet another level you have
> > to hit the power soft-button. This isn't fundamentally different from
> > powering off a USB peripheral that the system decides is idle (and then not
> > seeing input from it until something else wakes the system)
>
> The touchscreen on android devices is powered down long before we
> suspend, so that is not a good example. There is still a significant
> difference between suspend and idle though. In idle all interrupts
> work, in suspend only interrupts that the driver has called
> enable_irq_wake on will work (on platforms that support it).
>
> >> 3. � � �The system comes out of a deep idle state when a timer
> >> � � � �expires. �In contrast, timers cannot expire while the
> >> � � � �system is suspended. �(This one is debatable: some people
> >> � � � �argue that timers are subject to jitter, and the suspend
> >> � � � �case for timers is the same as that for deep idle states,
> >> � � � �but with unbounded timer jitter. �Others disagree. �The
> >> � � � �resulting discussions have produced much heat, but little
> >> � � � �light. �Such is life.)
> >
> > if you have the ability to wake for an alarm, you have the ability to wake
> > for a timer (if from no other method than to set the alarm to when the timer
> > tick would go off)
>
> If you just program the alarm you will wake up see that the monotonic
> clock has not advanced and set the alarm another n seconds into the
> future. Or are proposing that suspend should be changed to keep the
> monotonic clock running? If you are, why? We can enter the same
> hardware states from idle, and modifying suspend to wake up more often
> would increase the average power consumption in suspend, not improve
> it for idle. In other words, if suspend wakes up as often as idle, why
> use suspend?

Hmmm... The bit about the monotonic clock not advancing could help
explain at least some of the heartburn from the scheduler and real-time
folks. ;-)

My guess is that this is not a problem for Android workloads, which
probably do not contain aggressive real-time components. (With the
possible exception of interactions with the cellphone network, which
I believe are handled by a separate core with separate OS.) However,
pulling this into the Linux kernel would require that interactions with
aggressive real-time workloads be handled, one way or another.

I can see a couple possible resolutions:

1. Make OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT, so that
opportunistic suspend simply doesn't happen on systems that
support aggressive real-time workloads.

2. Allow OPPORTUNISTIC_SUSPEND and PREEMPT_RT, but suppress
opportunistic suspend when there is a user-created real-time
process. One way to handle this would be with a variation
on a tongue-in-cheek suggestion from Peter Zijlstra, namely
to have every real-time process hold a wakelock. Note that
such a wakelock would need to be held even if the real-time
process in question was not runnable, in order to meet
possible real-time deadlines when the real-time process was
awakened.

3. Your proposal here. ;-)

Thoughts?

Thanx, Paul

> >> There may well be others.
> >>
> >> Whether these distinctions are a good thing or a bad thing is one of
> >> the topics of this discussion. �But the distinctions themselves are
> >> certainly very real, from what I can see.
> >>
> >> Or am I missing your point?
> >
> > these big distinction that I see as significant seem to be in the decision
> > of when to go into the different states, and the difference between the
> > states �themselves seem to be less significant (and either very close to, or
> > within the variation that already exists for power saving modes)
> >
> > If I'm right bout this, then it would seem to simplify the concept and
> > change it from some really foreign android-only thing into a special case
> > variation of existing core concepts.
>
> Suspend is not an android only concept. The android extensions just
> allow us to aggressively use suspend without loosing (or delaying)
> wakeup events. On the hardware that we shipped we can enter the same
> power mode from idle as we do in suspend, but we still use suspend
> primarily because it stops the monotonic clock and all the timers that
> use it. Changing suspend to behave more like an idle mode, which seems
> to be what you are suggesting, would not buy us anything.
>
> >
> > you have many different power saving modes, the daemon (or kernel code) that
> > is determining which mode to go into would need different logic (including,
> > but not limited to the ability to be able to ignore one or more cgroups of
> > processes). different power saving modes have different trade-offs, and some
> > of them power down different peripherals (which is always a platform
> > specific, if not system specific set of trade-offs)
> >
>
> The hardware specific idle hook can (and does) decide to go into any
> power state from idle that does not disrupt any active devices.
>
> > This all depends on the ability for the code that decides to switch power
> > modes (including to trigger suspend) to be able to see things in sufficient
> > detail to be able to do different things depending on the class of programs.
> > I don't know enough about this code to know if this is the case or not, I
> > really wish that someone familiar with the power saving code could either
> > confirm that this is possible, or state that it's not possible (or at least,
> > not without major surgery)
> >
>
>
>
> --
> Arve Hj�nnev�g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/