Re: Runtime PM discussion notes

Re: Runtime PM discussion notes

[Paul Walmsley]

(cc'ing some lists)

Hi

a few thoughts here:

On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:

> On Tuesday, June 14, 2011, Magnus Damm wrote:
>
> > As for freezing user space, yes, I agree. The other feature including
> > a different set of wakeup sources, not so sure why you would want to
> > have that. I can't think of any good use case for that, from my point
> > of view system-wide suspend is more like the limping cousin of the
> > full-blown kernel.
> 
> Well, the freezing of user space by itself doesn't buy you anything
> power management-wise, you pretty much need to do the other things too to
> really save energy this way. 

Freezing user space stops CPU-hogging processes from running.  When the 
runqueue is empty, the scheduler can go idle.  This in turn allows the 
CPU(s) to enter low power sleep states via CPUIdle.

As I understand it, this is really the basis for the modern Android 
use-case for wakelocks and opportunistic suspend.  They prevent 
non-power-privileged userspace applications from keeping the system from 
entering a low-power state.  (Secondarily, suspend also prevents kernel 
code from running, e.g., timers set by filesystems, the networking stack, 
etc.; but problems here should be fixed in the offending kernel code, 
rather than hacked around, since some of the users of those timers could 
be important)

> Anyway, the value of system suspend is to allow the user to tell the system
> "OK, now I'm not going to use you for a while and I don't want the USB mouse
> to wake you up", so that the system can go into a state in which it draws
> minimum energy.
> 
> Of course, you can argue that the system may detect when it's not used and
> put itself into that state, which is somewhat correct, but the system can
> _never_ know two things by itself: (1) that it's not going to be used _in_
> _advance_

But suspend users don't know this either, since they can't predict when 
the next external wakeup can happen.

Having some kind of indication that the user is done using a device for 
the time being is definitely useful.  But that's separate from system 
suspend.  System suspend is just one of many actions that the system might 
choose to take when the user gives that indication.

Consider something like a screensaver.  Usually, the longer latency the 
wakeup operation is, the longer the screensaver waits before deciding to, 
say, power the monitor off, or put the system into suspend (as we 
discussed that Mac OS X does at LinuxCon Boston).  Similarly, if there is 
some background task that really needs to run, an intelligent system will 
not allow a power economization mode to prevent that from happening.

> and (2) that it is supposed to ignore wakeup signals from certain
> sources. 

Isn't this configurable now without system suspend with the wakeup sources 
code?

> As I said, support for system suspend allows the user to do more with the
> system and you really can't implement that functionality differently.  You
> may choose not to implement it at all, but why should you?

The individual components of system suspend are definitely useful:

1. preventing userspace processes from keeping the system from entering 
   idle
2. preventing userspace processes from waking the system back up
3. preventing kernel code from keeping the system from entering idle
4. preventing kernel code from waking the system back up
5. requesting that drivers abort what they are currently doing

The main issues are that these:

1. are all bundled up into one operation

2. target the entire universe of entities that they manage, rather than 
selectively targeting non-power-privileged entities


- Paul

Re: [linux-pm] Runtime PM discussion notes

[Alan Stern]

On Thu, 23 Jun 2011, Paul Walmsley wrote:

> Hi
> 
> a few thoughts here:
> 
> On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> 
> > On Tuesday, June 14, 2011, Magnus Damm wrote:
> >
> > > As for freezing user space, yes, I agree. The other feature including
> > > a different set of wakeup sources, not so sure why you would want to
> > > have that. I can't think of any good use case for that, from my point
> > > of view system-wide suspend is more like the limping cousin of the
> > > full-blown kernel.
> > 
> > Well, the freezing of user space by itself doesn't buy you anything
> > power management-wise, you pretty much need to do the other things too to
> > really save energy this way. 
> 
> Freezing user space stops CPU-hogging processes from running.  When the 
> runqueue is empty, the scheduler can go idle.  This in turn allows the 
> CPU(s) to enter low power sleep states via CPUIdle.

Very true.  At the moment, isn't it possible for the userspace 
ioctl PM interface to freeze processes without going all the way 
through to a system sleep?

> As I understand it, this is really the basis for the modern Android 
> use-case for wakelocks and opportunistic suspend.  They prevent 
> non-power-privileged userspace applications from keeping the system from 
> entering a low-power state.  (Secondarily, suspend also prevents kernel 
> code from running, e.g., timers set by filesystems, the networking stack, 
> etc.; but problems here should be fixed in the offending kernel code, 
> rather than hacked around, since some of the users of those timers could 
> be important)

I think you have oversimplified things a little, but never mind...

> > Anyway, the value of system suspend is to allow the user to tell the system
> > "OK, now I'm not going to use you for a while and I don't want the USB mouse
> > to wake you up", so that the system can go into a state in which it draws
> > minimum energy.
> > 
> > Of course, you can argue that the system may detect when it's not used and
> > put itself into that state, which is somewhat correct, but the system can
> > _never_ know two things by itself: (1) that it's not going to be used _in_
> > _advance_
> 
> But suspend users don't know this either, since they can't predict when 
> the next external wakeup can happen.

But they do know (or should know) that they don't intend to use the 
system in the near future.  It might be good to have a separate way to 
express that idea to the kernel.

> Having some kind of indication that the user is done using a device for 
> the time being is definitely useful.  But that's separate from system 
> suspend.  System suspend is just one of many actions that the system might 
> choose to take when the user gives that indication.
> 
> Consider something like a screensaver.  Usually, the longer latency the 
> wakeup operation is, the longer the screensaver waits before deciding to, 
> say, power the monitor off, or put the system into suspend (as we 
> discussed that Mac OS X does at LinuxCon Boston).  Similarly, if there is 
> some background task that really needs to run, an intelligent system will 
> not allow a power economization mode to prevent that from happening.
> 
> > and (2) that it is supposed to ignore wakeup signals from certain
> > sources. 
> 
> Isn't this configurable now without system suspend with the wakeup sources 
> code?

The wakeup code does two things: It tells the system which devices 
should be enabled for wakeup when the system sleeps (as opposed to 
cpuidle, when all devices should be able to generate interrupts), and 
it tells the system when a wakeup event has just occurred so that the 
system won't allow itself to go to sleep before the event can be 
processed.

> > As I said, support for system suspend allows the user to do more with the
> > system and you really can't implement that functionality differently.  You
> > may choose not to implement it at all, but why should you?
> 
> The individual components of system suspend are definitely useful:
> 
> 1. preventing userspace processes from keeping the system from entering 
>    idle
> 2. preventing userspace processes from waking the system back up

It's not clear what this means.  How can a user process wake the system 
up?  Are you referring to user timers?

Do we have a way (or want a way) to distinguish between user timers and
kernel timers?

> 3. preventing kernel code from keeping the system from entering idle

Relatively few kernel threads are freezable.  The ones that are tend to 
be involved in device management.  Did you have something specific in 
mind?

> 4. preventing kernel code from waking the system back up
> 5. requesting that drivers abort what they are currently doing

Not exactly "abort".  More like "stop processing their I/O queues".

> The main issues are that these:
> 
> 1. are all bundled up into one operation
> 
> 2. target the entire universe of entities that they manage, rather than 
> selectively targeting non-power-privileged entities

That's an interesting way of thinking about it.  Thanks for bringing 
it up.

Alan Stern

Re: [linux-pm] Runtime PM discussion notes

[Rafael J. Wysocki]

Hi,

On Thursday, June 23, 2011, Alan Stern wrote:
> On Thu, 23 Jun 2011, Paul Walmsley wrote:
> 
> > Hi
> > 
> > a few thoughts here:
> > 
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > 
> > > On Tuesday, June 14, 2011, Magnus Damm wrote:
> > >
> > > > As for freezing user space, yes, I agree. The other feature including
> > > > a different set of wakeup sources, not so sure why you would want to
> > > > have that. I can't think of any good use case for that, from my point
> > > > of view system-wide suspend is more like the limping cousin of the
> > > > full-blown kernel.
> > > 
> > > Well, the freezing of user space by itself doesn't buy you anything
> > > power management-wise, you pretty much need to do the other things too to
> > > really save energy this way. 
> > 
> > Freezing user space stops CPU-hogging processes from running.  When the 
> > runqueue is empty, the scheduler can go idle.  This in turn allows the 
> > CPU(s) to enter low power sleep states via CPUIdle.

But you don't have to freeze user space for this purpose, do you?
You may simply send a SIGSTOP to those processes.

> Very true.  At the moment, isn't it possible for the userspace 
> ioctl PM interface to freeze processes without going all the way 
> through to a system sleep?

Yes, it is.

> > As I understand it, this is really the basis for the modern Android 
> > use-case for wakelocks and opportunistic suspend.  They prevent 
> > non-power-privileged userspace applications from keeping the system from 
> > entering a low-power state.  (Secondarily, suspend also prevents kernel 
> > code from running, e.g., timers set by filesystems, the networking stack, 
> > etc.; but problems here should be fixed in the offending kernel code, 
> > rather than hacked around, since some of the users of those timers could 
> > be important)
> 
> I think you have oversimplified things a little, but never mind...

Well, saying "a little" is an overstatement. :-)

This was given as one of the arguments why using the wakelocks mechanism
along with the opportunistic suspend might be regarded as a good idea, but
I think the _real_ reason why it is used by Android is that the system
suspend framework was usable already when Android was being developed and if
they wanted to get acceptable battery lives at that time, they simply had no
choice but to use it.

> > > Anyway, the value of system suspend is to allow the user to tell the system
> > > "OK, now I'm not going to use you for a while and I don't want the USB mouse
> > > to wake you up", so that the system can go into a state in which it draws
> > > minimum energy.
> > > 
> > > Of course, you can argue that the system may detect when it's not used and
> > > put itself into that state, which is somewhat correct, but the system can
> > > _never_ know two things by itself: (1) that it's not going to be used _in_
> > > _advance_
> > 
> > But suspend users don't know this either, since they can't predict when 
> > the next external wakeup can happen.

That's going backwards somewhat.  First, a suspend user is supposed to choose
what devices can wake up the system in response to external events, so he
can choose to not allow any devices to do that.  Second, if external wakeup
sigals (and such that the user doesn't control directly) are enabled, this
basically means that the user allows someone else to wake up the system.
He may not know when this happens, but that's a bit like saying
"I don't need you now, but if someone else does, so be it."

> But they do know (or should know) that they don't intend to use the 
> system in the near future.  It might be good to have a separate way to 
> express that idea to the kernel.

Starting system suspend means exactly that: "Go to a sleep state, because
I'm not going to use you now (until I will wake you up)".

Now, you can set an RTC etc. to wake up the system from sleep states, so
people thought it might mean something different, but it simply doesn't.

> > Having some kind of indication that the user is done using a device for 
> > the time being is definitely useful.  But that's separate from system 
> > suspend.  System suspend is just one of many actions that the system might 
> > choose to take when the user gives that indication.

I generally agree, but "system" should not be confused with "the kernel".

Let me rephrase what I have already said for many times: system suspend
interface in the kernel is for user space, so that it can put the system into
a sleep state at any time.  The decision to use it need not be made
directly by the user, but from the kernel's point of view it doesn't matter.
The interface is there and it works how it works.

> > Consider something like a screensaver.  Usually, the longer latency the 
> > wakeup operation is, the longer the screensaver waits before deciding to, 
> > say, power the monitor off, or put the system into suspend (as we 
> > discussed that Mac OS X does at LinuxCon Boston).  Similarly, if there is 
> > some background task that really needs to run, an intelligent system will 
> > not allow a power economization mode to prevent that from happening.
> > 
> > > and (2) that it is supposed to ignore wakeup signals from certain
> > > sources. 
> > 
> > Isn't this configurable now without system suspend with the wakeup sources 
> > code?
> 
> The wakeup code does two things: It tells the system which devices 
> should be enabled for wakeup when the system sleeps (as opposed to 
> cpuidle, when all devices should be able to generate interrupts), and 
> it tells the system when a wakeup event has just occurred so that the 
> system won't allow itself to go to sleep before the event can be 
> processed.

I think I know what Paul meant here.  Namely, whether or not subsystems (or
platforms) can use this information in the runtime PM context.  In my opinion
that might be possible, but it would requre us to distinguish between situations
in which the wakeup setting should and should not be taken into account.

> > > As I said, support for system suspend allows the user to do more with the
> > > system and you really can't implement that functionality differently.  You
> > > may choose not to implement it at all, but why should you?
> > 
> > The individual components of system suspend are definitely useful:
> > 
> > 1. preventing userspace processes from keeping the system from entering 
> >    idle
> > 2. preventing userspace processes from waking the system back up
> 
> It's not clear what this means.  How can a user process wake the system 
> up?  Are you referring to user timers?
> 
> Do we have a way (or want a way) to distinguish between user timers and
> kernel timers?
> 
> > 3. preventing kernel code from keeping the system from entering idle
> 
> Relatively few kernel threads are freezable.  The ones that are tend to 
> be involved in device management.  Did you have something specific in 
> mind?
> 
> > 4. preventing kernel code from waking the system back up
> > 5. requesting that drivers abort what they are currently doing
> 
> Not exactly "abort".  More like "stop processing their I/O queues".
> 
> > The main issues are that these:
> > 
> > 1. are all bundled up into one operation
> > 
> > 2. target the entire universe of entities that they manage, rather than 
> > selectively targeting non-power-privileged entities
> 
> That's an interesting way of thinking about it.  Thanks for bringing 
> it up.

Quite frankly, it's not entirely new to me and I seem to remember it being
mentioned during the discussion following the Android wakelocks patches
submission.

Anyway, the system suspend (and hibernation) interface is what it is and
there are good reasons why it is desigened this way.  To me, as I said already
before, the question is not if it can be replaced with something else, because
it can't (there are platforms where something else won't work), but if a
given platofrm has a reason to support it.  That, of course, depends on the
platform in question, but surely every platform wanting to support Android
pretty much has to support the system suspend interface too. :-)

I, personally, think that there are good reasons to support it too, but my
reasons need not be everyone's reasons.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Paul Walmsley]

(Arve cc'ed, also adding Magnus and Kevin back to cc)

Hi Rafael,

On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:

> On Thursday, June 23, 2011, Alan Stern wrote:
> > On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > >
> > > > Well, the freezing of user space by itself doesn't buy you anything
> > > > power management-wise, you pretty much need to do the other things too to
> > > > really save energy this way. 
> > > 
> > > Freezing user space stops CPU-hogging processes from running.  When the 
> > > runqueue is empty, the scheduler can go idle.  This in turn allows the 
> > > CPU(s) to enter low power sleep states via CPUIdle.
> 
> But you don't have to freeze user space for this purpose, do you?
> You may simply send a SIGSTOP to those processes.

Probably that would be useful for some use-cases.  there are two 
issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing:

1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy 
with respect to system calls like setsid(), such that the sender may miss 
some processes;

2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for 
example 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19

> > > As I understand it, this is really the basis for the modern Android 
> > > use-case for wakelocks and opportunistic suspend.  They prevent 
> > > non-power-privileged userspace applications from keeping the system from 
> > > entering a low-power state.  (Secondarily, suspend also prevents kernel 
> > > code from running, e.g., timers set by filesystems, the networking stack, 
> > > etc.; but problems here should be fixed in the offending kernel code, 
> > > rather than hacked around, since some of the users of those timers could 
> > > be important)
> > 
> > I think you have oversimplified things a little, but never mind...
> 
> Well, saying "a little" is an overstatement. :-)

What parts do you feel were oversimplified?

> This was given as one of the arguments why using the wakelocks mechanism
> along with the opportunistic suspend might be regarded as a good idea, but
> I think the _real_ reason why it is used by Android is that the system
> suspend framework was usable already when Android was being developed and if
> they wanted to get acceptable battery lives at that time, they simply had no
> choice but to use it.

This is why "modern" was written in the original text: to contrast with 
the historical rationale for suspend blockers.

As I understand it, in the original Android implementation, the hardware 
that they were using didn't have fine-grained power management.  So 
system-wide suspend made more sense in that context.  But that shouldn't 
be confused with the modern rationale for wakelocks:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html

"On the hardware that shipped we enter the same power state from idle
and suspend, so the only power savings we get from suspend that we
don't get in idle is from not respecting the scheduler and timers."


- Paul

Re: [linux-pm] Runtime PM discussion notes

[Arve Hjønnevåg]

On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
...
>
> As I understand it, in the original Android implementation, the hardware
> that they were using didn't have fine-grained power management.  So
> system-wide suspend made more sense in that context.  But that shouldn't
> be confused with the modern rationale for wakelocks:
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
>
> "On the hardware that shipped we enter the same power state from idle
> and suspend, so the only power savings we get from suspend that we
> don't get in idle is from not respecting the scheduler and timers."
>

This is no longer the case. Both the Nexus-S and Xoom enter lower
power states from suspend than idle.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] Runtime PM discussion notes

[Magnus Damm]

2011/6/25 Arve Hjønnevåg <arve@android.com>:
> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> ...
>>
>> As I understand it, in the original Android implementation, the hardware
>> that they were using didn't have fine-grained power management.  So
>> system-wide suspend made more sense in that context.  But that shouldn't
>> be confused with the modern rationale for wakelocks:
>>
>> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
>>
>> "On the hardware that shipped we enter the same power state from idle
>> and suspend, so the only power savings we get from suspend that we
>> don't get in idle is from not respecting the scheduler and timers."
>>
>
> This is no longer the case. Both the Nexus-S and Xoom enter lower
> power states from suspend than idle.

Interesting, thanks for pointing that out. So this lower-power-state
in system suspend, is that a hardware limitation, or just a reflection
on effort spent on the CPUIdle portion of the current software
implementation? I suspect it's the latter.

I've recently been working towards implementing software support for
deeper sleep modes on sh7372 in the mainline kernel. With my
experimental patch the system suspend case may be able to sleep deeper
that current CPUIdle, but that's only because I have not yet tied in
enough dependency tracking to make proper decisions from CPUIdle
context.

Getting sleep modes working transparently with CPUIdle is currently a
bit more difficult than simply using system suspend IMO, so I would
not be surprised if some vendors simply skip implementing some deeper
sleep modes in CPUIdle due to the added complexity.

From the hardware perspective nothing is stopping us to use CPUIdle
with the lowest sleep states. This is true for all SH-Mobile SoCs
including sh7372. Also, we don't rely on firmware for control of the
PM states - if anyone is restricted by a firmware interface then
obviously it's going to be difficult to do more fine grained power
management.

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Runtime PM discussion notes

[Magnus Damm]

2011/6/25 Arve Hjønnevåg <arve@android.com>:
> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> ...
>>
>> As I understand it, in the original Android implementation, the hardware
>> that they were using didn't have fine-grained power management.  So
>> system-wide suspend made more sense in that context.  But that shouldn't
>> be confused with the modern rationale for wakelocks:
>>
>> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
>>
>> "On the hardware that shipped we enter the same power state from idle
>> and suspend, so the only power savings we get from suspend that we
>> don't get in idle is from not respecting the scheduler and timers."
>>
>
> This is no longer the case. Both the Nexus-S and Xoom enter lower
> power states from suspend than idle.

Interesting, thanks for pointing that out. So this lower-power-state
in system suspend, is that a hardware limitation, or just a reflection
on effort spent on the CPUIdle portion of the current software
implementation? I suspect it's the latter.

I've recently been working towards implementing software support for
deeper sleep modes on sh7372 in the mainline kernel. With my
experimental patch the system suspend case may be able to sleep deeper
that current CPUIdle, but that's only because I have not yet tied in
enough dependency tracking to make proper decisions from CPUIdle
context.

Getting sleep modes working transparently with CPUIdle is currently a
bit more difficult than simply using system suspend IMO, so I would
not be surprised if some vendors simply skip implementing some deeper
sleep modes in CPUIdle due to the added complexity.

>From the hardware perspective nothing is stopping us to use CPUIdle
with the lowest sleep states. This is true for all SH-Mobile SoCs
including sh7372. Also, we don't rely on firmware for control of the
PM states - if anyone is restricted by a firmware interface then
obviously it's going to be difficult to do more fine grained power
management.

Cheers,

/ magnus

Re: [linux-pm] Runtime PM discussion notes

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1091 bytes --]

Hello Arve,

On Fri, 24 Jun 2011, Arve Hjønnevåg wrote:

> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > As I understand it, in the original Android implementation, the hardware
> > that they were using didn't have fine-grained power management.  So
> > system-wide suspend made more sense in that context.  But that shouldn't
> > be confused with the modern rationale for wakelocks:
> >
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
> >
> > "On the hardware that shipped we enter the same power state from idle
> > and suspend, so the only power savings we get from suspend that we
> > don't get in idle is from not respecting the scheduler and timers."
> >
> 
> This is no longer the case. Both the Nexus-S and Xoom enter lower
> power states from suspend than idle.

Just out of curiosity, is that due to some kind of hardware limitation on 
those platforms, or is it because the software infrastructure for dynamic 
deep idle hasn't been fully implemented in that subarchitecture code?


- Paul

Re: Runtime PM discussion notes

[Mark Brown]

On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:

> > > "On the hardware that shipped we enter the same power state from idle
> > > and suspend, so the only power savings we get from suspend that we
> > > don't get in idle is from not respecting the scheduler and timers."

> > This is no longer the case. Both the Nexus-S and Xoom enter lower
> > power states from suspend than idle.

> Just out of curiosity, is that due to some kind of hardware limitation on 
> those platforms, or is it because the software infrastructure for dynamic 
> deep idle hasn't been fully implemented in that subarchitecture code?

At least the Nexus S doesn't implmeent any of the deep idle
infrastructure.  However, I'd expect that you can achieve some power
saving from entering system suspend as if *everything* is off then the
PMIC can be suspended which can enable additional power savings.  Unless
I'm missing something that'd be hard to hit with cpuidle only stuff.

Re: [linux-pm] Runtime PM discussion notes

[Mark Brown]

On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:

> > > "On the hardware that shipped we enter the same power state from idle
> > > and suspend, so the only power savings we get from suspend that we
> > > don't get in idle is from not respecting the scheduler and timers."

> > This is no longer the case. Both the Nexus-S and Xoom enter lower
> > power states from suspend than idle.

> Just out of curiosity, is that due to some kind of hardware limitation on 
> those platforms, or is it because the software infrastructure for dynamic 
> deep idle hasn't been fully implemented in that subarchitecture code?

At least the Nexus S doesn't implmeent any of the deep idle
infrastructure.  However, I'd expect that you can achieve some power
saving from entering system suspend as if *everything* is off then the
PMIC can be suspended which can enable additional power savings.  Unless
I'm missing something that'd be hard to hit with cpuidle only stuff.

Re: Runtime PM discussion notes

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:
> On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> > On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> 
> > > > "On the hardware that shipped we enter the same power state from idle
> > > > and suspend, so the only power savings we get from suspend that we
> > > > don't get in idle is from not respecting the scheduler and timers."
> 
> > > This is no longer the case. Both the Nexus-S and Xoom enter lower
> > > power states from suspend than idle.
> 
> > Just out of curiosity, is that due to some kind of hardware limitation on 
> > those platforms, or is it because the software infrastructure for dynamic 
> > deep idle hasn't been fully implemented in that subarchitecture code?
> 
> At least the Nexus S doesn't implmeent any of the deep idle
> infrastructure.  However, I'd expect that you can achieve some power
> saving from entering system suspend as if *everything* is off then the
> PMIC can be suspended which can enable additional power savings.  Unless
> I'm missing something that'd be hard to hit with cpuidle only stuff.

You should be able to hit the same states from idle no problem. At that
point the only things on are memory in retention and some wake-up timer.
Even the timer could be off if you have hardware wake-up events, but then
system timer won't work the noral way naturally.

The only way power down everything in suspend to disk :) Most PMICs have
some functionality always on so they can charge the battery when it's
empty.

Regards,

Tony

Re: [linux-pm] Runtime PM discussion notes

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:
> On Tue, Jun 28, 2011 at 01:47:47PM -0600, Paul Walmsley wrote:
> > On Fri, 24 Jun 2011, Arve Hj?nnev?g wrote:
> > > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> 
> > > > "On the hardware that shipped we enter the same power state from idle
> > > > and suspend, so the only power savings we get from suspend that we
> > > > don't get in idle is from not respecting the scheduler and timers."
> 
> > > This is no longer the case. Both the Nexus-S and Xoom enter lower
> > > power states from suspend than idle.
> 
> > Just out of curiosity, is that due to some kind of hardware limitation on 
> > those platforms, or is it because the software infrastructure for dynamic 
> > deep idle hasn't been fully implemented in that subarchitecture code?
> 
> At least the Nexus S doesn't implmeent any of the deep idle
> infrastructure.  However, I'd expect that you can achieve some power
> saving from entering system suspend as if *everything* is off then the
> PMIC can be suspended which can enable additional power savings.  Unless
> I'm missing something that'd be hard to hit with cpuidle only stuff.

You should be able to hit the same states from idle no problem. At that
point the only things on are memory in retention and some wake-up timer.
Even the timer could be off if you have hardware wake-up events, but then
system timer won't work the noral way naturally.

The only way power down everything in suspend to disk :) Most PMICs have
some functionality always on so they can charge the battery when it's
empty.

Regards,

Tony

Re: [linux-pm] Runtime PM discussion notes

[Mark Brown]

On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:

> > At least the Nexus S doesn't implmeent any of the deep idle
> > infrastructure.  However, I'd expect that you can achieve some power
> > saving from entering system suspend as if *everything* is off then the
> > PMIC can be suspended which can enable additional power savings.  Unless
> > I'm missing something that'd be hard to hit with cpuidle only stuff.

> You should be able to hit the same states from idle no problem. At that
> point the only things on are memory in retention and some wake-up timer.
> Even the timer could be off if you have hardware wake-up events, but then
> system timer won't work the noral way naturally.

Right, but it can be interesting to tell the PMIC that we went into this
mode.  Possibly cpuidle will end up doing this as a result of signals
generated as the CPU core goes down, but at that point it's just s2ram
by another name.

> The only way power down everything in suspend to disk :) Most PMICs have
> some functionality always on so they can charge the battery when it's
> empty.

With some PMICs the truly always on functionality is *very* minimal and
doesn't include chargers, it can be pretty much limited to wake sources
(including power status changes which might start charging if power
appears).

Re: [linux-pm] Runtime PM discussion notes

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:
> On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:
> 
> > > At least the Nexus S doesn't implmeent any of the deep idle
> > > infrastructure.  However, I'd expect that you can achieve some power
> > > saving from entering system suspend as if *everything* is off then the
> > > PMIC can be suspended which can enable additional power savings.  Unless
> > > I'm missing something that'd be hard to hit with cpuidle only stuff.
> 
> > You should be able to hit the same states from idle no problem. At that
> > point the only things on are memory in retention and some wake-up timer.
> > Even the timer could be off if you have hardware wake-up events, but then
> > system timer won't work the noral way naturally.
> 
> Right, but it can be interesting to tell the PMIC that we went into this
> mode.  Possibly cpuidle will end up doing this as a result of signals
> generated as the CPU core goes down, but at that point it's just s2ram
> by another name.

All PMIC devices should be shut down when not in use, so I don't know
what else you would configure in the PMIC. Maybe you have something else
there to configure? Just curious what kind of mess you have to deal with
compared to the mess I need to deal with :)

Also, hitting deeper sleep states from idle is not same as suspend to ram.
With suspend to ram the system timer is killed while timers behave in a
normal way when hitting deeper sleep states from idle.
 
> > The only way power down everything in suspend to disk :) Most PMICs have
> > some functionality always on so they can charge the battery when it's
> > empty.
> 
> With some PMICs the truly always on functionality is *very* minimal and
> doesn't include chargers, it can be pretty much limited to wake sources
> (including power status changes which might start charging if power
> appears).

Sure.

Tony

Re: Runtime PM discussion notes

[Mark Brown]

On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:

> > Right, but it can be interesting to tell the PMIC that we went into this
> > mode.  Possibly cpuidle will end up doing this as a result of signals
> > generated as the CPU core goes down, but at that point it's just s2ram
> > by another name.

> All PMIC devices should be shut down when not in use, so I don't know
> what else you would configure in the PMIC. Maybe you have something else
> there to configure? Just curious what kind of mess you have to deal with
> compared to the mess I need to deal with :)

The interesting bits are things like being able to kill lots of the SoC
core supplies when the RAM is in retention mode - the CPU needs to go
through its shutdown procedures.

> Also, hitting deeper sleep states from idle is not same as suspend to ram.
> With suspend to ram the system timer is killed while timers behave in a
> normal way when hitting deeper sleep states from idle.

Actually, it just occurred to me that if we're waiting for a system
timer and can hand that off to a suitable timer in the PMIC then we can
do a suspend to RAM for the deep idle state from the hardware point of
view.

Re: [linux-pm] Runtime PM discussion notes

[Mark Brown]

On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:

> > Right, but it can be interesting to tell the PMIC that we went into this
> > mode.  Possibly cpuidle will end up doing this as a result of signals
> > generated as the CPU core goes down, but at that point it's just s2ram
> > by another name.

> All PMIC devices should be shut down when not in use, so I don't know
> what else you would configure in the PMIC. Maybe you have something else
> there to configure? Just curious what kind of mess you have to deal with
> compared to the mess I need to deal with :)

The interesting bits are things like being able to kill lots of the SoC
core supplies when the RAM is in retention mode - the CPU needs to go
through its shutdown procedures.

> Also, hitting deeper sleep states from idle is not same as suspend to ram.
> With suspend to ram the system timer is killed while timers behave in a
> normal way when hitting deeper sleep states from idle.

Actually, it just occurred to me that if we're waiting for a system
timer and can hand that off to a suitable timer in the PMIC then we can
do a suspend to RAM for the deep idle state from the hardware point of
view.

Re: Runtime PM discussion notes

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 04:21]:
> On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:
> 
> > > Right, but it can be interesting to tell the PMIC that we went into this
> > > mode.  Possibly cpuidle will end up doing this as a result of signals
> > > generated as the CPU core goes down, but at that point it's just s2ram
> > > by another name.
> 
> > All PMIC devices should be shut down when not in use, so I don't know
> > what else you would configure in the PMIC. Maybe you have something else
> > there to configure? Just curious what kind of mess you have to deal with
> > compared to the mess I need to deal with :)
> 
> The interesting bits are things like being able to kill lots of the SoC
> core supplies when the RAM is in retention mode - the CPU needs to go
> through its shutdown procedures.

I see. I've seen cases these are pre-programmed to the PMIC and then
automatically triggered based on some event like WFI.
 
> > Also, hitting deeper sleep states from idle is not same as suspend to ram.
> > With suspend to ram the system timer is killed while timers behave in a
> > normal way when hitting deeper sleep states from idle.
> 
> Actually, it just occurred to me that if we're waiting for a system
> timer and can hand that off to a suitable timer in the PMIC then we can
> do a suspend to RAM for the deep idle state from the hardware point of
> view.

Cool, it would be nice to have a Linux generic way for programming a
separate hardware wake-up timer. Not RTC, but some more accurate timer that
might be too slow to access for general purpose usage.

Regards,

Tony

Re: [linux-pm] Runtime PM discussion notes

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 04:21]:
> On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:
> 
> > > Right, but it can be interesting to tell the PMIC that we went into this
> > > mode.  Possibly cpuidle will end up doing this as a result of signals
> > > generated as the CPU core goes down, but at that point it's just s2ram
> > > by another name.
> 
> > All PMIC devices should be shut down when not in use, so I don't know
> > what else you would configure in the PMIC. Maybe you have something else
> > there to configure? Just curious what kind of mess you have to deal with
> > compared to the mess I need to deal with :)
> 
> The interesting bits are things like being able to kill lots of the SoC
> core supplies when the RAM is in retention mode - the CPU needs to go
> through its shutdown procedures.

I see. I've seen cases these are pre-programmed to the PMIC and then
automatically triggered based on some event like WFI.
 
> > Also, hitting deeper sleep states from idle is not same as suspend to ram.
> > With suspend to ram the system timer is killed while timers behave in a
> > normal way when hitting deeper sleep states from idle.
> 
> Actually, it just occurred to me that if we're waiting for a system
> timer and can hand that off to a suitable timer in the PMIC then we can
> do a suspend to RAM for the deep idle state from the hardware point of
> view.

Cool, it would be nice to have a Linux generic way for programming a
separate hardware wake-up timer. Not RTC, but some more accurate timer that
might be too slow to access for general purpose usage.

Regards,

Tony

Re: [linux-pm] Runtime PM discussion notes

[Paul Walmsley]

(cc'ing Len)

Hi Mark,

On Mon, 11 Jul 2011, Mark Brown wrote:

> The interesting bits are things like being able to kill lots of the SoC
> core supplies when the RAM is in retention mode - the CPU needs to go
> through its shutdown procedures.

This is indeed possible on OMAP3+ chips with TWL4030+ PMICs.  Probably 
other PMICs also.  TI calls it "off-mode."  The N900 shipped with this 
feature enabled.  Not sure how many other similar products did.

This can be enabled in mainline, but not all of the mainline drivers have 
context save/restore code merged yet, so in mainline it only works with a 
subset of drivers.

> Actually, it just occurred to me that if we're waiting for a system
> timer and can hand that off to a suitable timer in the PMIC then we can
> do a suspend to RAM for the deep idle state from the hardware point of
> view.

Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
whether it would be possible to enter ACPI S-states from CPUIdle (or some 
idle governor) on Intel chips.  If I remember correctly, the conclusion 
was that ACPI always disables the screen/backlight, so it would only be 
useful for situations where that was acceptable.

To the best of my (limited) knowledge, that's the only case I know of 
where there's a hardware limitation that prevents dynamic idle from 
reaching the same low power state as system suspend.  If someone has hard 
details of a similar example, it would be great to know about it.


- Paul

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

On Wednesday, July 13, 2011, Paul Walmsley wrote:
> (cc'ing Len)
> 
> Hi Mark,
> 
> On Mon, 11 Jul 2011, Mark Brown wrote:
> 
> > The interesting bits are things like being able to kill lots of the SoC
> > core supplies when the RAM is in retention mode - the CPU needs to go
> > through its shutdown procedures.
> 
> This is indeed possible on OMAP3+ chips with TWL4030+ PMICs.  Probably 
> other PMICs also.  TI calls it "off-mode."  The N900 shipped with this 
> feature enabled.  Not sure how many other similar products did.
> 
> This can be enabled in mainline, but not all of the mainline drivers have 
> context save/restore code merged yet, so in mainline it only works with a 
> subset of drivers.
> 
> > Actually, it just occurred to me that if we're waiting for a system
> > timer and can hand that off to a suitable timer in the PMIC then we can
> > do a suspend to RAM for the deep idle state from the hardware point of
> > view.
> 
> Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
> whether it would be possible to enter ACPI S-states from CPUIdle (or some 
> idle governor) on Intel chips.  If I remember correctly, the conclusion 
> was that ACPI always disables the screen/backlight, so it would only be 
> useful for situations where that was acceptable.

The reason why you can't enter ACPI S-states from CPUidle is because you
need to go out of the idle loop to execute some ACPI-specific stuff.  Which
is not even specific to Intel chips, but to ACPI in general.

So entering ACPI S-states from idle is a no-no and I don't think it'll
change in foreseeable future.

> To the best of my (limited) knowledge, that's the only case I know of 
> where there's a hardware limitation that prevents dynamic idle from 
> reaching the same low power state as system suspend.  If someone has hard 
> details of a similar example, it would be great to know about it.

Google G1 had this problem IIRC, but I don't have any details.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Rafael J. Wysocki]

On Wednesday, July 13, 2011, Paul Walmsley wrote:
> (cc'ing Len)
> 
> Hi Mark,
> 
> On Mon, 11 Jul 2011, Mark Brown wrote:
> 
> > The interesting bits are things like being able to kill lots of the SoC
> > core supplies when the RAM is in retention mode - the CPU needs to go
> > through its shutdown procedures.
> 
> This is indeed possible on OMAP3+ chips with TWL4030+ PMICs.  Probably 
> other PMICs also.  TI calls it "off-mode."  The N900 shipped with this 
> feature enabled.  Not sure how many other similar products did.
> 
> This can be enabled in mainline, but not all of the mainline drivers have 
> context save/restore code merged yet, so in mainline it only works with a 
> subset of drivers.
> 
> > Actually, it just occurred to me that if we're waiting for a system
> > timer and can hand that off to a suitable timer in the PMIC then we can
> > do a suspend to RAM for the deep idle state from the hardware point of
> > view.
> 
> Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
> whether it would be possible to enter ACPI S-states from CPUIdle (or some 
> idle governor) on Intel chips.  If I remember correctly, the conclusion 
> was that ACPI always disables the screen/backlight, so it would only be 
> useful for situations where that was acceptable.

The reason why you can't enter ACPI S-states from CPUidle is because you
need to go out of the idle loop to execute some ACPI-specific stuff.  Which
is not even specific to Intel chips, but to ACPI in general.

So entering ACPI S-states from idle is a no-no and I don't think it'll
change in foreseeable future.

> To the best of my (limited) knowledge, that's the only case I know of 
> where there's a hardware limitation that prevents dynamic idle from 
> reaching the same low power state as system suspend.  If someone has hard 
> details of a similar example, it would be great to know about it.

Google G1 had this problem IIRC, but I don't have any details.

Thanks,
Rafael

Re: Runtime PM discussion notes

[Pavel Machek]

Hi!

> > > Actually, it just occurred to me that if we're waiting for a system
> > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > do a suspend to RAM for the deep idle state from the hardware point of
> > > view.
> > 
> > Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
> > whether it would be possible to enter ACPI S-states from CPUIdle (or some 
> > idle governor) on Intel chips.  If I remember correctly, the conclusion 
> > was that ACPI always disables the screen/backlight, so it would only be 
> > useful for situations where that was acceptable.

Well, auto suspending when screensaver is active would still be
useful.

(And IIRC some machines kept screen on when in S-state unless driver
powered it down... but that might be S1.

> The reason why you can't enter ACPI S-states from CPUidle is because you
> need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> is not even specific to Intel chips, but to ACPI in general.

The code was little tricky/unclean, but it "worked" for me at one
point... I called it  "sleepy linux".
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] Runtime PM discussion notes

[Pavel Machek]

Hi!

> > > Actually, it just occurred to me that if we're waiting for a system
> > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > do a suspend to RAM for the deep idle state from the hardware point of
> > > view.
> > 
> > Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
> > whether it would be possible to enter ACPI S-states from CPUIdle (or some 
> > idle governor) on Intel chips.  If I remember correctly, the conclusion 
> > was that ACPI always disables the screen/backlight, so it would only be 
> > useful for situations where that was acceptable.

Well, auto suspending when screensaver is active would still be
useful.

(And IIRC some machines kept screen on when in S-state unless driver
powered it down... but that might be S1.

> The reason why you can't enter ACPI S-states from CPUidle is because you
> need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> is not even specific to Intel chips, but to ACPI in general.

The code was little tricky/unclean, but it "worked" for me at one
point... I called it  "sleepy linux".
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

On Friday, July 29, 2011, Pavel Machek wrote:
> Hi!
> 
> > > > Actually, it just occurred to me that if we're waiting for a system
> > > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > > do a suspend to RAM for the deep idle state from the hardware point of
> > > > view.
> > > 
> > > Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
> > > whether it would be possible to enter ACPI S-states from CPUIdle (or some 
> > > idle governor) on Intel chips.  If I remember correctly, the conclusion 
> > > was that ACPI always disables the screen/backlight, so it would only be 
> > > useful for situations where that was acceptable.
> 
> Well, auto suspending when screensaver is active would still be
> useful.
> 
> (And IIRC some machines kept screen on when in S-state unless driver
> powered it down... but that might be S1.
> 
> > The reason why you can't enter ACPI S-states from CPUidle is because you
> > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > is not even specific to Intel chips, but to ACPI in general.
> 
> The code was little tricky/unclean, but it "worked" for me at one
> point... I called it  "sleepy linux".

Yes, you can find a system where it might kind of work (just because
_PTS is empty or something like this).  Is it going to work in general?
No way.

So please let's turn into something at least _theoretically_ viable.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Rafael J. Wysocki]

On Friday, July 29, 2011, Pavel Machek wrote:
> Hi!
> 
> > > > Actually, it just occurred to me that if we're waiting for a system
> > > > timer and can hand that off to a suitable timer in the PMIC then we can
> > > > do a suspend to RAM for the deep idle state from the hardware point of
> > > > view.
> > > 
> > > Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
> > > whether it would be possible to enter ACPI S-states from CPUIdle (or some 
> > > idle governor) on Intel chips.  If I remember correctly, the conclusion 
> > > was that ACPI always disables the screen/backlight, so it would only be 
> > > useful for situations where that was acceptable.
> 
> Well, auto suspending when screensaver is active would still be
> useful.
> 
> (And IIRC some machines kept screen on when in S-state unless driver
> powered it down... but that might be S1.
> 
> > The reason why you can't enter ACPI S-states from CPUidle is because you
> > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > is not even specific to Intel chips, but to ACPI in general.
> 
> The code was little tricky/unclean, but it "worked" for me at one
> point... I called it  "sleepy linux".

Yes, you can find a system where it might kind of work (just because
_PTS is empty or something like this).  Is it going to work in general?
No way.

So please let's turn into something at least _theoretically_ viable.

Thanks,
Rafael

Re: Runtime PM discussion notes

[Pavel Machek]

Hi!

> > Well, auto suspending when screensaver is active would still be
> > useful.
> > 
> > (And IIRC some machines kept screen on when in S-state unless driver
> > powered it down... but that might be S1.
> > 
> > > The reason why you can't enter ACPI S-states from CPUidle is because you
> > > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > > is not even specific to Intel chips, but to ACPI in general.
> > 
> > The code was little tricky/unclean, but it "worked" for me at one
> > point... I called it  "sleepy linux".
> 
> Yes, you can find a system where it might kind of work (just because
> _PTS is empty or something like this).  Is it going to work in general?
> No way.

IIRC I solved it by just calling _PTS when sleepy Linux was
enabled. It had side effect of lighting up moon icon, but otherwise
seemed to work ok.

I do not think ACPI says what can and can not be done after _PTS...


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] Runtime PM discussion notes

[Pavel Machek]

Hi!

> > Well, auto suspending when screensaver is active would still be
> > useful.
> > 
> > (And IIRC some machines kept screen on when in S-state unless driver
> > powered it down... but that might be S1.
> > 
> > > The reason why you can't enter ACPI S-states from CPUidle is because you
> > > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > > is not even specific to Intel chips, but to ACPI in general.
> > 
> > The code was little tricky/unclean, but it "worked" for me at one
> > point... I called it  "sleepy linux".
> 
> Yes, you can find a system where it might kind of work (just because
> _PTS is empty or something like this).  Is it going to work in general?
> No way.

IIRC I solved it by just calling _PTS when sleepy Linux was
enabled. It had side effect of lighting up moon icon, but otherwise
seemed to work ok.

I do not think ACPI says what can and can not be done after _PTS...


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

On Saturday, July 30, 2011, Pavel Machek wrote:
> Hi!
> 
> > > Well, auto suspending when screensaver is active would still be
> > > useful.
> > > 
> > > (And IIRC some machines kept screen on when in S-state unless driver
> > > powered it down... but that might be S1.
> > > 
> > > > The reason why you can't enter ACPI S-states from CPUidle is because you
> > > > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > > > is not even specific to Intel chips, but to ACPI in general.
> > > 
> > > The code was little tricky/unclean, but it "worked" for me at one
> > > point... I called it  "sleepy linux".
> > 
> > Yes, you can find a system where it might kind of work (just because
> > _PTS is empty or something like this).  Is it going to work in general?
> > No way.
> 
> IIRC I solved it by just calling _PTS when sleepy Linux was
> enabled. It had side effect of lighting up moon icon, but otherwise
> seemed to work ok.
> 
> I do not think ACPI says what can and can not be done after _PTS...

Yes, it does.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Rafael J. Wysocki]

On Saturday, July 30, 2011, Pavel Machek wrote:
> Hi!
> 
> > > Well, auto suspending when screensaver is active would still be
> > > useful.
> > > 
> > > (And IIRC some machines kept screen on when in S-state unless driver
> > > powered it down... but that might be S1.
> > > 
> > > > The reason why you can't enter ACPI S-states from CPUidle is because you
> > > > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > > > is not even specific to Intel chips, but to ACPI in general.
> > > 
> > > The code was little tricky/unclean, but it "worked" for me at one
> > > point... I called it  "sleepy linux".
> > 
> > Yes, you can find a system where it might kind of work (just because
> > _PTS is empty or something like this).  Is it going to work in general?
> > No way.
> 
> IIRC I solved it by just calling _PTS when sleepy Linux was
> enabled. It had side effect of lighting up moon icon, but otherwise
> seemed to work ok.
> 
> I do not think ACPI says what can and can not be done after _PTS...

Yes, it does.

Thanks,
Rafael

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

On Saturday, July 30, 2011, Rafael J. Wysocki wrote:
> On Saturday, July 30, 2011, Pavel Machek wrote:
> > Hi!
> > 
> > > > Well, auto suspending when screensaver is active would still be
> > > > useful.
> > > > 
> > > > (And IIRC some machines kept screen on when in S-state unless driver
> > > > powered it down... but that might be S1.
> > > > 
> > > > > The reason why you can't enter ACPI S-states from CPUidle is because you
> > > > > need to go out of the idle loop to execute some ACPI-specific stuff.  Which
> > > > > is not even specific to Intel chips, but to ACPI in general.
> > > > 
> > > > The code was little tricky/unclean, but it "worked" for me at one
> > > > point... I called it  "sleepy linux".
> > > 
> > > Yes, you can find a system where it might kind of work (just because
> > > _PTS is empty or something like this).  Is it going to work in general?
> > > No way.
> > 
> > IIRC I solved it by just calling _PTS when sleepy Linux was
> > enabled. It had side effect of lighting up moon icon, but otherwise
> > seemed to work ok.
> > 
> > I do not think ACPI says what can and can not be done after _PTS...
> 
> Yes, it does.

And even if _PTS will work, you're certainly not supposed to execute _WAK
with interrupts off.

Thanks,
Rafael

Re: Runtime PM discussion notes

[Pavel Machek]

> > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > seemed to work ok.
> > > 
> > > I do not think ACPI says what can and can not be done after _PTS...
> > 
> > Yes, it does.
> 
> And even if _PTS will work, you're certainly not supposed to execute _WAK
> with interrupts off.

It should be ok to execute _WAK in process context once system is
resumed. ... or maybe not executing _WAK at all. User can probably
live with moon icon lighted up.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] Runtime PM discussion notes

[Pavel Machek]

> > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > seemed to work ok.
> > > 
> > > I do not think ACPI says what can and can not be done after _PTS...
> > 
> > Yes, it does.
> 
> And even if _PTS will work, you're certainly not supposed to execute _WAK
> with interrupts off.

It should be ok to execute _WAK in process context once system is
resumed. ... or maybe not executing _WAK at all. User can probably
live with moon icon lighted up.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

On Saturday, July 30, 2011, Pavel Machek wrote:
> 
> > > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > > seemed to work ok.
> > > > 
> > > > I do not think ACPI says what can and can not be done after _PTS...
> > > 
> > > Yes, it does.
> > 
> > And even if _PTS will work, you're certainly not supposed to execute _WAK
> > with interrupts off.
> 
> It should be ok to execute _WAK in process context once system is
> resumed. ... or maybe not executing _WAK at all. User can probably
> live with moon icon lighted up.

But I don't think the user can live with certain functionality missing,
like battery status or such things.

This is completely unrealistic to think that your prototype can be safely
implemented on _every_ ACPI-based system.  Period.

And that's even without taking SMP into account, BTW.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Rafael J. Wysocki]

On Saturday, July 30, 2011, Pavel Machek wrote:
> 
> > > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > > seemed to work ok.
> > > > 
> > > > I do not think ACPI says what can and can not be done after _PTS...
> > > 
> > > Yes, it does.
> > 
> > And even if _PTS will work, you're certainly not supposed to execute _WAK
> > with interrupts off.
> 
> It should be ok to execute _WAK in process context once system is
> resumed. ... or maybe not executing _WAK at all. User can probably
> live with moon icon lighted up.

But I don't think the user can live with certain functionality missing,
like battery status or such things.

This is completely unrealistic to think that your prototype can be safely
implemented on _every_ ACPI-based system.  Period.

And that's even without taking SMP into account, BTW.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Pavel Machek]

Hi!

> > IIRC I solved it by just calling _PTS when sleepy Linux was
> > enabled. It had side effect of lighting up moon icon, but otherwise
> > seemed to work ok.
> > 
> > I do not think ACPI says what can and can not be done after _PTS...
> 
> Yes, it does.

I have 2.0 spec here; it explains how _PTS can be called long time
before actual sleep and may not power down devices...

> > It should be ok to execute _WAK in process context once system is
> > resumed. ... or maybe not executing _WAK at all. User can probably
> > live with moon icon lighted up.
> 
> But I don't think the user can live with certain functionality missing,
> like battery status or such things.

Yep; you'd probably want to execute it before calling other ACPI methods...

> This is completely unrealistic to think that your prototype can be safely
> implemented on _every_ ACPI-based system.  Period.

My prototype would probably not be safe on any system, period. It was
quick hack to prove the concept.

> And that's even without taking SMP into account, BTW.

Idea was to do hot CPU unplug before enabling sleepy state. Sleepy
probably should be enabled when screen is turned off by
screensaver (if machine is sufficiently idle).

I'm not saying that task is easy, merely that is doable. (Doing it in
clean way will be harder still). Basically prepare all the devices to
sleep when machine gets "idle enough", along with _PTS, but keep
running, including userspace. Then, if next wake up is "long enough"
into future, set up RTC alarm and push machine to sleep.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

On Sunday, July 31, 2011, Pavel Machek wrote:
> Hi!
> 
> > > IIRC I solved it by just calling _PTS when sleepy Linux was
> > > enabled. It had side effect of lighting up moon icon, but otherwise
> > > seemed to work ok.
> > > 
> > > I do not think ACPI says what can and can not be done after _PTS...
> > 
> > Yes, it does.
> 
> I have 2.0 spec here; it explains how _PTS can be called long time
> before actual sleep and may not power down devices...
> 
> > > It should be ok to execute _WAK in process context once system is
> > > resumed. ... or maybe not executing _WAK at all. User can probably
> > > live with moon icon lighted up.
> > 
> > But I don't think the user can live with certain functionality missing,
> > like battery status or such things.
> 
> Yep; you'd probably want to execute it before calling other ACPI methods...
> 
> > This is completely unrealistic to think that your prototype can be safely
> > implemented on _every_ ACPI-based system.  Period.
> 
> My prototype would probably not be safe on any system, period. It was
> quick hack to prove the concept.
> 
> > And that's even without taking SMP into account, BTW.
> 
> Idea was to do hot CPU unplug before enabling sleepy state. Sleepy
> probably should be enabled when screen is turned off by
> screensaver (if machine is sufficiently idle).
> 
> I'm not saying that task is easy, merely that is doable. (Doing it in
> clean way will be harder still). Basically prepare all the devices to
> sleep when machine gets "idle enough", along with _PTS, but keep
> running, including userspace. Then, if next wake up is "long enough"
> into future, set up RTC alarm and push machine to sleep.

You're supposed to do all that from within the idle loop on one
of the CPUs (at least in the context of this discussion).  I don't
really think it's realistically doable.

Thanks,
Rafael

Re: Runtime PM discussion notes

[Pavel Machek]

Hi!

> > IIRC I solved it by just calling _PTS when sleepy Linux was
> > enabled. It had side effect of lighting up moon icon, but otherwise
> > seemed to work ok.
> > 
> > I do not think ACPI says what can and can not be done after _PTS...
> 
> Yes, it does.

I have 2.0 spec here; it explains how _PTS can be called long time
before actual sleep and may not power down devices...

> > It should be ok to execute _WAK in process context once system is
> > resumed. ... or maybe not executing _WAK at all. User can probably
> > live with moon icon lighted up.
> 
> But I don't think the user can live with certain functionality missing,
> like battery status or such things.

Yep; you'd probably want to execute it before calling other ACPI methods...

> This is completely unrealistic to think that your prototype can be safely
> implemented on _every_ ACPI-based system.  Period.

My prototype would probably not be safe on any system, period. It was
quick hack to prove the concept.

> And that's even without taking SMP into account, BTW.

Idea was to do hot CPU unplug before enabling sleepy state. Sleepy
probably should be enabled when screen is turned off by
screensaver (if machine is sufficiently idle).

I'm not saying that task is easy, merely that is doable. (Doing it in
clean way will be harder still). Basically prepare all the devices to
sleep when machine gets "idle enough", along with _PTS, but keep
running, including userspace. Then, if next wake up is "long enough"
into future, set up RTC alarm and push machine to sleep.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Runtime PM discussion notes

[Paul Walmsley]

(cc'ing Len)

Hi Mark,

On Mon, 11 Jul 2011, Mark Brown wrote:

> The interesting bits are things like being able to kill lots of the SoC
> core supplies when the RAM is in retention mode - the CPU needs to go
> through its shutdown procedures.

This is indeed possible on OMAP3+ chips with TWL4030+ PMICs.  Probably 
other PMICs also.  TI calls it "off-mode."  The N900 shipped with this 
feature enabled.  Not sure how many other similar products did.

This can be enabled in mainline, but not all of the mainline drivers have 
context save/restore code merged yet, so in mainline it only works with a 
subset of drivers.

> Actually, it just occurred to me that if we're waiting for a system
> timer and can hand that off to a suitable timer in the PMIC then we can
> do a suspend to RAM for the deep idle state from the hardware point of
> view.

Yep.  At LinuxCon Cambridge two years ago, we had a discussion about 
whether it would be possible to enter ACPI S-states from CPUIdle (or some 
idle governor) on Intel chips.  If I remember correctly, the conclusion 
was that ACPI always disables the screen/backlight, so it would only be 
useful for situations where that was acceptable.

To the best of my (limited) knowledge, that's the only case I know of 
where there's a hardware limitation that prevents dynamic idle from 
reaching the same low power state as system suspend.  If someone has hard 
details of a similar example, it would be great to know about it.


- Paul

Re: Runtime PM discussion notes

[Tony Lindgren]

* Mark Brown <broonie@opensource.wolfsonmicro.com> [110711 03:59]:
> On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:
> 
> > > At least the Nexus S doesn't implmeent any of the deep idle
> > > infrastructure.  However, I'd expect that you can achieve some power
> > > saving from entering system suspend as if *everything* is off then the
> > > PMIC can be suspended which can enable additional power savings.  Unless
> > > I'm missing something that'd be hard to hit with cpuidle only stuff.
> 
> > You should be able to hit the same states from idle no problem. At that
> > point the only things on are memory in retention and some wake-up timer.
> > Even the timer could be off if you have hardware wake-up events, but then
> > system timer won't work the noral way naturally.
> 
> Right, but it can be interesting to tell the PMIC that we went into this
> mode.  Possibly cpuidle will end up doing this as a result of signals
> generated as the CPU core goes down, but at that point it's just s2ram
> by another name.

All PMIC devices should be shut down when not in use, so I don't know
what else you would configure in the PMIC. Maybe you have something else
there to configure? Just curious what kind of mess you have to deal with
compared to the mess I need to deal with :)

Also, hitting deeper sleep states from idle is not same as suspend to ram.
With suspend to ram the system timer is killed while timers behave in a
normal way when hitting deeper sleep states from idle.
 
> > The only way power down everything in suspend to disk :) Most PMICs have
> > some functionality always on so they can charge the battery when it's
> > empty.
> 
> With some PMICs the truly always on functionality is *very* minimal and
> doesn't include chargers, it can be pretty much limited to wake sources
> (including power status changes which might start charging if power
> appears).

Sure.

Tony

Re: Runtime PM discussion notes

[Mark Brown]

On Mon, Jul 11, 2011 at 02:58:12AM -0700, Tony Lindgren wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [110708 21:01]:

> > At least the Nexus S doesn't implmeent any of the deep idle
> > infrastructure.  However, I'd expect that you can achieve some power
> > saving from entering system suspend as if *everything* is off then the
> > PMIC can be suspended which can enable additional power savings.  Unless
> > I'm missing something that'd be hard to hit with cpuidle only stuff.

> You should be able to hit the same states from idle no problem. At that
> point the only things on are memory in retention and some wake-up timer.
> Even the timer could be off if you have hardware wake-up events, but then
> system timer won't work the noral way naturally.

Right, but it can be interesting to tell the PMIC that we went into this
mode.  Possibly cpuidle will end up doing this as a result of signals
generated as the CPU core goes down, but at that point it's just s2ram
by another name.

> The only way power down everything in suspend to disk :) Most PMICs have
> some functionality always on so they can charge the battery when it's
> empty.

With some PMICs the truly always on functionality is *very* minimal and
doesn't include chargers, it can be pretty much limited to wake sources
(including power status changes which might start charging if power
appears).

Re: Runtime PM discussion notes

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1091 bytes --]

Hello Arve,

On Fri, 24 Jun 2011, Arve Hjønnevåg wrote:

> On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > As I understand it, in the original Android implementation, the hardware
> > that they were using didn't have fine-grained power management.  So
> > system-wide suspend made more sense in that context.  But that shouldn't
> > be confused with the modern rationale for wakelocks:
> >
> > https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
> >
> > "On the hardware that shipped we enter the same power state from idle
> > and suspend, so the only power savings we get from suspend that we
> > don't get in idle is from not respecting the scheduler and timers."
> >
> 
> This is no longer the case. Both the Nexus-S and Xoom enter lower
> power states from suspend than idle.

Just out of curiosity, is that due to some kind of hardware limitation on 
those platforms, or is it because the software infrastructure for dynamic 
deep idle hasn't been fully implemented in that subarchitecture code?


- Paul

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Runtime PM discussion notes

[Arve Hjønnevåg]

On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@pwsan.com> wrote:
...
>
> As I understand it, in the original Android implementation, the hardware
> that they were using didn't have fine-grained power management.  So
> system-wide suspend made more sense in that context.  But that shouldn't
> be confused with the modern rationale for wakelocks:
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
>
> "On the hardware that shipped we enter the same power state from idle
> and suspend, so the only power savings we get from suspend that we
> don't get in idle is from not respecting the scheduler and timers."
>

This is no longer the case. Both the Nexus-S and Xoom enter lower
power states from suspend than idle.

-- 
Arve Hjønnevåg

Re: [linux-pm] Runtime PM discussion notes

[Rafael J. Wysocki]

Hi,

On Friday, June 24, 2011, Paul Walmsley wrote:
> (Arve cc'ed, also adding Magnus and Kevin back to cc)

Thanks, my mailer is playing tricks on me. :-)

> Hi Rafael,
> 
> On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:
> 
> > On Thursday, June 23, 2011, Alan Stern wrote:
> > > On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > > > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > > >
> > > > > Well, the freezing of user space by itself doesn't buy you anything
> > > > > power management-wise, you pretty much need to do the other things too to
> > > > > really save energy this way. 
> > > > 
> > > > Freezing user space stops CPU-hogging processes from running.  When the 
> > > > runqueue is empty, the scheduler can go idle.  This in turn allows the 
> > > > CPU(s) to enter low power sleep states via CPUIdle.
> > 
> > But you don't have to freeze user space for this purpose, do you?
> > You may simply send a SIGSTOP to those processes.
> 
> Probably that would be useful for some use-cases.  there are two 
> issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing:
> 
> 1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy 
> with respect to system calls like setsid(), such that the sender may miss 
> some processes;

I must admit I don't know the details here, but that sounds quite plausible.

> 2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for 
> example 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19

That's correct, but on the other hand some user space processes want to be
notified that they're going to be frozen (like NetworkManager, although it
probably wants that because of the suspend that's going to happen next).

My point here is that being observable need not be a bad thing, depending on
the viewpoint.

> > > > As I understand it, this is really the basis for the modern Android 
> > > > use-case for wakelocks and opportunistic suspend.  They prevent 
> > > > non-power-privileged userspace applications from keeping the system from 
> > > > entering a low-power state.  (Secondarily, suspend also prevents kernel 
> > > > code from running, e.g., timers set by filesystems, the networking stack, 
> > > > etc.; but problems here should be fixed in the offending kernel code, 
> > > > rather than hacked around, since some of the users of those timers could 
> > > > be important)
> > > 
> > > I think you have oversimplified things a little, but never mind...
> > 
> > Well, saying "a little" is an overstatement. :-)
> 
> What parts do you feel were oversimplified?

In fact, there are several things that wakelocks are being used for, including
the one you have mentioned, but also:

* Idleness detection (meaning "whole system idleness).
* Detection of races between system suspend and wakeup events.
* Collecting wakeup events statistics (useful for detection of misbehaving
  applications).

The system idleness detection mechanism probably makes the most of the
difference between Android and other Linux-based systems PM-wise.

> > This was given as one of the arguments why using the wakelocks mechanism
> > along with the opportunistic suspend might be regarded as a good idea, but
> > I think the _real_ reason why it is used by Android is that the system
> > suspend framework was usable already when Android was being developed and if
> > they wanted to get acceptable battery lives at that time, they simply had no
> > choice but to use it.
> 
> This is why "modern" was written in the original text: to contrast with 
> the historical rationale for suspend blockers.
> 
> As I understand it, in the original Android implementation, the hardware 
> that they were using didn't have fine-grained power management.  So 
> system-wide suspend made more sense in that context.  But that shouldn't 
> be confused with the modern rationale for wakelocks:
> 
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
> 
> "On the hardware that shipped we enter the same power state from idle
> and suspend, so the only power savings we get from suspend that we
> don't get in idle is from not respecting the scheduler and timers."

There is a point in that, because timers wake up the CPU from low-power
states entered through CPUuidle.

Anyway, I don't quite get your point overall in the ongoing discussion.
I'd like to understand it, so we know we're talking about the same things. :-)

You seem to be making a point for not supporting system suspend.  That may
mean two different things, though.

First, you may be trying to say that system suspend is a bad idea in general
and it shouldn't be supported at all.  That I strongly disagree with, because
there are platforms where it is the only effective way of saving energy
on systems that are not in use, but should become available quickly if
necessary.  Moreover, there are systems where system suspend makes it possible
to save more energy than CPUidle and runtime PM combined.

Second, your point may be that for some platforms system suspend is not worth
supporting.  I don't agree with that too, although not so strongly.  To be
precise, in my opinion that is a matter of balance between the number of
features the given platform wants to support and the time and effort needed to
implement that support.

Of course, I think that system suspend is one of the features which, if
supported, make a platform more attractive from the point of view of potential
users (where I don't really mean end users, but people wanting to build a
product on top of it), but you can say that I'm biased, because I've been
working on system suspend for a long time and you may be right. :-)
That said I think that the support for system suspend is not too difficult to
implement and the benefits are readily visible.  Your opinion may be different,
but I don't see anything wrong with that as long as it is based on technical
arguments.

To conclude, the kernel will support system suspend in its current form as
long as that depends on me to any extent.  On the other hand, I'm not going to
force anyone to support it.  After all, there are platforms that don't support
system suspend right now and live with that just fine. :-)

Thanks,
Rafael

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

Hi,

On Friday, June 24, 2011, Paul Walmsley wrote:
> (Arve cc'ed, also adding Magnus and Kevin back to cc)

Thanks, my mailer is playing tricks on me. :-)

> Hi Rafael,
> 
> On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:
> 
> > On Thursday, June 23, 2011, Alan Stern wrote:
> > > On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > > > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > > >
> > > > > Well, the freezing of user space by itself doesn't buy you anything
> > > > > power management-wise, you pretty much need to do the other things too to
> > > > > really save energy this way. 
> > > > 
> > > > Freezing user space stops CPU-hogging processes from running.  When the 
> > > > runqueue is empty, the scheduler can go idle.  This in turn allows the 
> > > > CPU(s) to enter low power sleep states via CPUIdle.
> > 
> > But you don't have to freeze user space for this purpose, do you?
> > You may simply send a SIGSTOP to those processes.
> 
> Probably that would be useful for some use-cases.  there are two 
> issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing:
> 
> 1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy 
> with respect to system calls like setsid(), such that the sender may miss 
> some processes;

I must admit I don't know the details here, but that sounds quite plausible.

> 2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for 
> example 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19

That's correct, but on the other hand some user space processes want to be
notified that they're going to be frozen (like NetworkManager, although it
probably wants that because of the suspend that's going to happen next).

My point here is that being observable need not be a bad thing, depending on
the viewpoint.

> > > > As I understand it, this is really the basis for the modern Android 
> > > > use-case for wakelocks and opportunistic suspend.  They prevent 
> > > > non-power-privileged userspace applications from keeping the system from 
> > > > entering a low-power state.  (Secondarily, suspend also prevents kernel 
> > > > code from running, e.g., timers set by filesystems, the networking stack, 
> > > > etc.; but problems here should be fixed in the offending kernel code, 
> > > > rather than hacked around, since some of the users of those timers could 
> > > > be important)
> > > 
> > > I think you have oversimplified things a little, but never mind...
> > 
> > Well, saying "a little" is an overstatement. :-)
> 
> What parts do you feel were oversimplified?

In fact, there are several things that wakelocks are being used for, including
the one you have mentioned, but also:

* Idleness detection (meaning "whole system idleness).
* Detection of races between system suspend and wakeup events.
* Collecting wakeup events statistics (useful for detection of misbehaving
  applications).

The system idleness detection mechanism probably makes the most of the
difference between Android and other Linux-based systems PM-wise.

> > This was given as one of the arguments why using the wakelocks mechanism
> > along with the opportunistic suspend might be regarded as a good idea, but
> > I think the _real_ reason why it is used by Android is that the system
> > suspend framework was usable already when Android was being developed and if
> > they wanted to get acceptable battery lives at that time, they simply had no
> > choice but to use it.
> 
> This is why "modern" was written in the original text: to contrast with 
> the historical rationale for suspend blockers.
> 
> As I understand it, in the original Android implementation, the hardware 
> that they were using didn't have fine-grained power management.  So 
> system-wide suspend made more sense in that context.  But that shouldn't 
> be confused with the modern rationale for wakelocks:
> 
> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html
> 
> "On the hardware that shipped we enter the same power state from idle
> and suspend, so the only power savings we get from suspend that we
> don't get in idle is from not respecting the scheduler and timers."

There is a point in that, because timers wake up the CPU from low-power
states entered through CPUuidle.

Anyway, I don't quite get your point overall in the ongoing discussion.
I'd like to understand it, so we know we're talking about the same things. :-)

You seem to be making a point for not supporting system suspend.  That may
mean two different things, though.

First, you may be trying to say that system suspend is a bad idea in general
and it shouldn't be supported at all.  That I strongly disagree with, because
there are platforms where it is the only effective way of saving energy
on systems that are not in use, but should become available quickly if
necessary.  Moreover, there are systems where system suspend makes it possible
to save more energy than CPUidle and runtime PM combined.

Second, your point may be that for some platforms system suspend is not worth
supporting.  I don't agree with that too, although not so strongly.  To be
precise, in my opinion that is a matter of balance between the number of
features the given platform wants to support and the time and effort needed to
implement that support.

Of course, I think that system suspend is one of the features which, if
supported, make a platform more attractive from the point of view of potential
users (where I don't really mean end users, but people wanting to build a
product on top of it), but you can say that I'm biased, because I've been
working on system suspend for a long time and you may be right. :-)
That said I think that the support for system suspend is not too difficult to
implement and the benefits are readily visible.  Your opinion may be different,
but I don't see anything wrong with that as long as it is based on technical
arguments.

To conclude, the kernel will support system suspend in its current form as
long as that depends on me to any extent.  On the other hand, I'm not going to
force anyone to support it.  After all, there are platforms that don't support
system suspend right now and live with that just fine. :-)

Thanks,
Rafael

Re: Runtime PM discussion notes

[Paul Walmsley]

(Arve cc'ed, also adding Magnus and Kevin back to cc)

Hi Rafael,

On Thu, 23 Jun 2011, Rafael J. Wysocki wrote:

> On Thursday, June 23, 2011, Alan Stern wrote:
> > On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > >
> > > > Well, the freezing of user space by itself doesn't buy you anything
> > > > power management-wise, you pretty much need to do the other things too to
> > > > really save energy this way. 
> > > 
> > > Freezing user space stops CPU-hogging processes from running.  When the 
> > > runqueue is empty, the scheduler can go idle.  This in turn allows the 
> > > CPU(s) to enter low power sleep states via CPUIdle.
> 
> But you don't have to freeze user space for this purpose, do you?
> You may simply send a SIGSTOP to those processes.

Probably that would be useful for some use-cases.  there are two 
issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing:

1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy 
with respect to system calls like setsid(), such that the sender may miss 
some processes;

2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for 
example 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19

> > > As I understand it, this is really the basis for the modern Android 
> > > use-case for wakelocks and opportunistic suspend.  They prevent 
> > > non-power-privileged userspace applications from keeping the system from 
> > > entering a low-power state.  (Secondarily, suspend also prevents kernel 
> > > code from running, e.g., timers set by filesystems, the networking stack, 
> > > etc.; but problems here should be fixed in the offending kernel code, 
> > > rather than hacked around, since some of the users of those timers could 
> > > be important)
> > 
> > I think you have oversimplified things a little, but never mind...
> 
> Well, saying "a little" is an overstatement. :-)

What parts do you feel were oversimplified?

> This was given as one of the arguments why using the wakelocks mechanism
> along with the opportunistic suspend might be regarded as a good idea, but
> I think the _real_ reason why it is used by Android is that the system
> suspend framework was usable already when Android was being developed and if
> they wanted to get acceptable battery lives at that time, they simply had no
> choice but to use it.

This is why "modern" was written in the original text: to contrast with 
the historical rationale for suspend blockers.

As I understand it, in the original Android implementation, the hardware 
that they were using didn't have fine-grained power management.  So 
system-wide suspend made more sense in that context.  But that shouldn't 
be confused with the modern rationale for wakelocks:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html

"On the hardware that shipped we enter the same power state from idle
and suspend, so the only power savings we get from suspend that we
don't get in idle is from not respecting the scheduler and timers."


- Paul

Re: Runtime PM discussion notes

[Rafael J. Wysocki]

Hi,

On Thursday, June 23, 2011, Alan Stern wrote:
> On Thu, 23 Jun 2011, Paul Walmsley wrote:
> 
> > Hi
> > 
> > a few thoughts here:
> > 
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> > 
> > > On Tuesday, June 14, 2011, Magnus Damm wrote:
> > >
> > > > As for freezing user space, yes, I agree. The other feature including
> > > > a different set of wakeup sources, not so sure why you would want to
> > > > have that. I can't think of any good use case for that, from my point
> > > > of view system-wide suspend is more like the limping cousin of the
> > > > full-blown kernel.
> > > 
> > > Well, the freezing of user space by itself doesn't buy you anything
> > > power management-wise, you pretty much need to do the other things too to
> > > really save energy this way. 
> > 
> > Freezing user space stops CPU-hogging processes from running.  When the 
> > runqueue is empty, the scheduler can go idle.  This in turn allows the 
> > CPU(s) to enter low power sleep states via CPUIdle.

But you don't have to freeze user space for this purpose, do you?
You may simply send a SIGSTOP to those processes.

> Very true.  At the moment, isn't it possible for the userspace 
> ioctl PM interface to freeze processes without going all the way 
> through to a system sleep?

Yes, it is.

> > As I understand it, this is really the basis for the modern Android 
> > use-case for wakelocks and opportunistic suspend.  They prevent 
> > non-power-privileged userspace applications from keeping the system from 
> > entering a low-power state.  (Secondarily, suspend also prevents kernel 
> > code from running, e.g., timers set by filesystems, the networking stack, 
> > etc.; but problems here should be fixed in the offending kernel code, 
> > rather than hacked around, since some of the users of those timers could 
> > be important)
> 
> I think you have oversimplified things a little, but never mind...

Well, saying "a little" is an overstatement. :-)

This was given as one of the arguments why using the wakelocks mechanism
along with the opportunistic suspend might be regarded as a good idea, but
I think the _real_ reason why it is used by Android is that the system
suspend framework was usable already when Android was being developed and if
they wanted to get acceptable battery lives at that time, they simply had no
choice but to use it.

> > > Anyway, the value of system suspend is to allow the user to tell the system
> > > "OK, now I'm not going to use you for a while and I don't want the USB mouse
> > > to wake you up", so that the system can go into a state in which it draws
> > > minimum energy.
> > > 
> > > Of course, you can argue that the system may detect when it's not used and
> > > put itself into that state, which is somewhat correct, but the system can
> > > _never_ know two things by itself: (1) that it's not going to be used _in_
> > > _advance_
> > 
> > But suspend users don't know this either, since they can't predict when 
> > the next external wakeup can happen.

That's going backwards somewhat.  First, a suspend user is supposed to choose
what devices can wake up the system in response to external events, so he
can choose to not allow any devices to do that.  Second, if external wakeup
sigals (and such that the user doesn't control directly) are enabled, this
basically means that the user allows someone else to wake up the system.
He may not know when this happens, but that's a bit like saying
"I don't need you now, but if someone else does, so be it."

> But they do know (or should know) that they don't intend to use the 
> system in the near future.  It might be good to have a separate way to 
> express that idea to the kernel.

Starting system suspend means exactly that: "Go to a sleep state, because
I'm not going to use you now (until I will wake you up)".

Now, you can set an RTC etc. to wake up the system from sleep states, so
people thought it might mean something different, but it simply doesn't.

> > Having some kind of indication that the user is done using a device for 
> > the time being is definitely useful.  But that's separate from system 
> > suspend.  System suspend is just one of many actions that the system might 
> > choose to take when the user gives that indication.

I generally agree, but "system" should not be confused with "the kernel".

Let me rephrase what I have already said for many times: system suspend
interface in the kernel is for user space, so that it can put the system into
a sleep state at any time.  The decision to use it need not be made
directly by the user, but from the kernel's point of view it doesn't matter.
The interface is there and it works how it works.

> > Consider something like a screensaver.  Usually, the longer latency the 
> > wakeup operation is, the longer the screensaver waits before deciding to, 
> > say, power the monitor off, or put the system into suspend (as we 
> > discussed that Mac OS X does at LinuxCon Boston).  Similarly, if there is 
> > some background task that really needs to run, an intelligent system will 
> > not allow a power economization mode to prevent that from happening.
> > 
> > > and (2) that it is supposed to ignore wakeup signals from certain
> > > sources. 
> > 
> > Isn't this configurable now without system suspend with the wakeup sources 
> > code?
> 
> The wakeup code does two things: It tells the system which devices 
> should be enabled for wakeup when the system sleeps (as opposed to 
> cpuidle, when all devices should be able to generate interrupts), and 
> it tells the system when a wakeup event has just occurred so that the 
> system won't allow itself to go to sleep before the event can be 
> processed.

I think I know what Paul meant here.  Namely, whether or not subsystems (or
platforms) can use this information in the runtime PM context.  In my opinion
that might be possible, but it would requre us to distinguish between situations
in which the wakeup setting should and should not be taken into account.

> > > As I said, support for system suspend allows the user to do more with the
> > > system and you really can't implement that functionality differently.  You
> > > may choose not to implement it at all, but why should you?
> > 
> > The individual components of system suspend are definitely useful:
> > 
> > 1. preventing userspace processes from keeping the system from entering 
> >    idle
> > 2. preventing userspace processes from waking the system back up
> 
> It's not clear what this means.  How can a user process wake the system 
> up?  Are you referring to user timers?
> 
> Do we have a way (or want a way) to distinguish between user timers and
> kernel timers?
> 
> > 3. preventing kernel code from keeping the system from entering idle
> 
> Relatively few kernel threads are freezable.  The ones that are tend to 
> be involved in device management.  Did you have something specific in 
> mind?
> 
> > 4. preventing kernel code from waking the system back up
> > 5. requesting that drivers abort what they are currently doing
> 
> Not exactly "abort".  More like "stop processing their I/O queues".
> 
> > The main issues are that these:
> > 
> > 1. are all bundled up into one operation
> > 
> > 2. target the entire universe of entities that they manage, rather than 
> > selectively targeting non-power-privileged entities
> 
> That's an interesting way of thinking about it.  Thanks for bringing 
> it up.

Quite frankly, it's not entirely new to me and I seem to remember it being
mentioned during the discussion following the Android wakelocks patches
submission.

Anyway, the system suspend (and hibernation) interface is what it is and
there are good reasons why it is desigened this way.  To me, as I said already
before, the question is not if it can be replaced with something else, because
it can't (there are platforms where something else won't work), but if a
given platofrm has a reason to support it.  That, of course, depends on the
platform in question, but surely every platform wanting to support Android
pretty much has to support the system suspend interface too. :-)

I, personally, think that there are good reasons to support it too, but my
reasons need not be everyone's reasons.

Thanks,
Rafael

Re: [linux-pm] Runtime PM discussion notes

[Paul Walmsley]

Hi Alan,

On Thu, 23 Jun 2011, Alan Stern wrote:

> On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > 
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
>
> At the moment, isn't it possible for the userspace ioctl PM interface to 
> freeze processes without going all the way through to a system sleep?

Something like cgroup_freezer is probably more useful, since it can freeze 
a configurable subset of processes.  Consider the common mobile use-case 
of audio playback while the display, touchscreen, etc. are disabled.  
In such a case, large portions of userspace can be frozen or paused, but 
not all.

> > But suspend users don't know this either, since they can't predict when 
> > the next external wakeup can happen.
> 
> But they do know (or should know) that they don't intend to use the 
> system in the near future.  It might be good to have a separate way to 
> express that idea to the kernel.

Are you thinking of the current userspace interfaces to suspend, or 
something else?

> > > and (2) that it is supposed to ignore wakeup signals from certain
> > > sources. 
> > 
> > Isn't this configurable now without system suspend with the wakeup sources 
> > code?
> 
> The wakeup code does two things: It tells the system which devices 
> should be enabled for wakeup when the system sleeps (as opposed to 
> cpuidle, when all devices should be able to generate interrupts),

Perhaps the same interface would be useful for CPUIdle-based approaches.

> > The individual components of system suspend are definitely useful:
> > 
> > 1. preventing userspace processes from keeping the system from entering 
> >    idle
> > 2. preventing userspace processes from waking the system back up
> 
> It's not clear what this means.  How can a user process wake the system 
> up?  Are you referring to user timers?

Yes.

> > 3. preventing kernel code from keeping the system from entering idle
> 
> Relatively few kernel threads are freezable.  The ones that are tend to 
> be involved in device management.  Did you have something specific in 
> mind?

No, nothing specific.

> > 4. preventing kernel code from waking the system back up
> > 5. requesting that drivers abort what they are currently doing
> 
> Not exactly "abort".  More like "stop processing their I/O queues".

Yes, that's a better way of putting it; hopefully most drivers are doing 
that.


- Paul

Re: Runtime PM discussion notes

[Alan Stern]

On Fri, 24 Jun 2011, Paul Walmsley wrote:

> > > But suspend users don't know this either, since they can't predict when 
> > > the next external wakeup can happen.
> > 
> > But they do know (or should know) that they don't intend to use the 
> > system in the near future.  It might be good to have a separate way to 
> > express that idea to the kernel.
> 
> Are you thinking of the current userspace interfaces to suspend, or 
> something else?

I'm not thinking of anything in particular.  Just brainstorming...

If somebody decides to freeze userspace without putting the entire 
system to sleep, how will they know when to unfreeze?  A certain amount 
of specialized kernel/userspace interaction would be needed.

> > > 1. preventing userspace processes from keeping the system from entering 
> > >    idle
> > > 2. preventing userspace processes from waking the system back up
> > 
> > It's not clear what this means.  How can a user process wake the system 
> > up?  Are you referring to user timers?
> 
> Yes.

Then those two are almost the same thing.  It doesn't seem to make much 
sense to say "I want to stop these processes from running now, but 
allow them to run if one of them gets a timer or I/O signal".

> > > 3. preventing kernel code from keeping the system from entering idle
> > 
> > Relatively few kernel threads are freezable.  The ones that are tend to 
> > be involved in device management.  Did you have something specific in 
> > mind?
> 
> No, nothing specific.
> 
> > > 4. preventing kernel code from waking the system back up

Once userspace is inactive, the kernel probably doesn't have very much
to do.  Responding to some network packets, maybe, if the network
interfaces are left running (like a router but without support for
dynamic routing protocols).  In general, I don't think a system could
do a whole lot of useful work in such a state.

> > > 5. requesting that drivers abort what they are currently doing
> > 
> > Not exactly "abort".  More like "stop processing their I/O queues".
> 
> Yes, that's a better way of putting it; hopefully most drivers are doing 
> that.

This is more of a "transition" issue than a "steady-state" concern.  
When userspace is frozen, it can't generate new I/O requests.  If the 
old ones were left to terminate normally, pretty soon the I/O queues 
would drain by themselves.

In short, I'm not sure how these ideas would yield anything new and 
worthwhile.  Maybe I'm just slow today...

Alan Stern

Re: [linux-pm] Runtime PM discussion notes

[Alan Stern]

On Fri, 24 Jun 2011, Paul Walmsley wrote:

> > > But suspend users don't know this either, since they can't predict when 
> > > the next external wakeup can happen.
> > 
> > But they do know (or should know) that they don't intend to use the 
> > system in the near future.  It might be good to have a separate way to 
> > express that idea to the kernel.
> 
> Are you thinking of the current userspace interfaces to suspend, or 
> something else?

I'm not thinking of anything in particular.  Just brainstorming...

If somebody decides to freeze userspace without putting the entire 
system to sleep, how will they know when to unfreeze?  A certain amount 
of specialized kernel/userspace interaction would be needed.

> > > 1. preventing userspace processes from keeping the system from entering 
> > >    idle
> > > 2. preventing userspace processes from waking the system back up
> > 
> > It's not clear what this means.  How can a user process wake the system 
> > up?  Are you referring to user timers?
> 
> Yes.

Then those two are almost the same thing.  It doesn't seem to make much 
sense to say "I want to stop these processes from running now, but 
allow them to run if one of them gets a timer or I/O signal".

> > > 3. preventing kernel code from keeping the system from entering idle
> > 
> > Relatively few kernel threads are freezable.  The ones that are tend to 
> > be involved in device management.  Did you have something specific in 
> > mind?
> 
> No, nothing specific.
> 
> > > 4. preventing kernel code from waking the system back up

Once userspace is inactive, the kernel probably doesn't have very much
to do.  Responding to some network packets, maybe, if the network
interfaces are left running (like a router but without support for
dynamic routing protocols).  In general, I don't think a system could
do a whole lot of useful work in such a state.

> > > 5. requesting that drivers abort what they are currently doing
> > 
> > Not exactly "abort".  More like "stop processing their I/O queues".
> 
> Yes, that's a better way of putting it; hopefully most drivers are doing 
> that.

This is more of a "transition" issue than a "steady-state" concern.  
When userspace is frozen, it can't generate new I/O requests.  If the 
old ones were left to terminate normally, pretty soon the I/O queues 
would drain by themselves.

In short, I'm not sure how these ideas would yield anything new and 
worthwhile.  Maybe I'm just slow today...

Alan Stern

Re: Runtime PM discussion notes

[Paul Walmsley]

Hi Alan,

On Thu, 23 Jun 2011, Alan Stern wrote:

> On Thu, 23 Jun 2011, Paul Walmsley wrote:
> > 
> > On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
>
> At the moment, isn't it possible for the userspace ioctl PM interface to 
> freeze processes without going all the way through to a system sleep?

Something like cgroup_freezer is probably more useful, since it can freeze 
a configurable subset of processes.  Consider the common mobile use-case 
of audio playback while the display, touchscreen, etc. are disabled.  
In such a case, large portions of userspace can be frozen or paused, but 
not all.

> > But suspend users don't know this either, since they can't predict when 
> > the next external wakeup can happen.
> 
> But they do know (or should know) that they don't intend to use the 
> system in the near future.  It might be good to have a separate way to 
> express that idea to the kernel.

Are you thinking of the current userspace interfaces to suspend, or 
something else?

> > > and (2) that it is supposed to ignore wakeup signals from certain
> > > sources. 
> > 
> > Isn't this configurable now without system suspend with the wakeup sources 
> > code?
> 
> The wakeup code does two things: It tells the system which devices 
> should be enabled for wakeup when the system sleeps (as opposed to 
> cpuidle, when all devices should be able to generate interrupts),

Perhaps the same interface would be useful for CPUIdle-based approaches.

> > The individual components of system suspend are definitely useful:
> > 
> > 1. preventing userspace processes from keeping the system from entering 
> >    idle
> > 2. preventing userspace processes from waking the system back up
> 
> It's not clear what this means.  How can a user process wake the system 
> up?  Are you referring to user timers?

Yes.

> > 3. preventing kernel code from keeping the system from entering idle
> 
> Relatively few kernel threads are freezable.  The ones that are tend to 
> be involved in device management.  Did you have something specific in 
> mind?

No, nothing specific.

> > 4. preventing kernel code from waking the system back up
> > 5. requesting that drivers abort what they are currently doing
> 
> Not exactly "abort".  More like "stop processing their I/O queues".

Yes, that's a better way of putting it; hopefully most drivers are doing 
that.


- Paul

Re: Runtime PM discussion notes

[Alan Stern]

On Thu, 23 Jun 2011, Paul Walmsley wrote:

> Hi
> 
> a few thoughts here:
> 
> On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:
> 
> > On Tuesday, June 14, 2011, Magnus Damm wrote:
> >
> > > As for freezing user space, yes, I agree. The other feature including
> > > a different set of wakeup sources, not so sure why you would want to
> > > have that. I can't think of any good use case for that, from my point
> > > of view system-wide suspend is more like the limping cousin of the
> > > full-blown kernel.
> > 
> > Well, the freezing of user space by itself doesn't buy you anything
> > power management-wise, you pretty much need to do the other things too to
> > really save energy this way. 
> 
> Freezing user space stops CPU-hogging processes from running.  When the 
> runqueue is empty, the scheduler can go idle.  This in turn allows the 
> CPU(s) to enter low power sleep states via CPUIdle.

Very true.  At the moment, isn't it possible for the userspace 
ioctl PM interface to freeze processes without going all the way 
through to a system sleep?

> As I understand it, this is really the basis for the modern Android 
> use-case for wakelocks and opportunistic suspend.  They prevent 
> non-power-privileged userspace applications from keeping the system from 
> entering a low-power state.  (Secondarily, suspend also prevents kernel 
> code from running, e.g., timers set by filesystems, the networking stack, 
> etc.; but problems here should be fixed in the offending kernel code, 
> rather than hacked around, since some of the users of those timers could 
> be important)

I think you have oversimplified things a little, but never mind...

> > Anyway, the value of system suspend is to allow the user to tell the system
> > "OK, now I'm not going to use you for a while and I don't want the USB mouse
> > to wake you up", so that the system can go into a state in which it draws
> > minimum energy.
> > 
> > Of course, you can argue that the system may detect when it's not used and
> > put itself into that state, which is somewhat correct, but the system can
> > _never_ know two things by itself: (1) that it's not going to be used _in_
> > _advance_
> 
> But suspend users don't know this either, since they can't predict when 
> the next external wakeup can happen.

But they do know (or should know) that they don't intend to use the 
system in the near future.  It might be good to have a separate way to 
express that idea to the kernel.

> Having some kind of indication that the user is done using a device for 
> the time being is definitely useful.  But that's separate from system 
> suspend.  System suspend is just one of many actions that the system might 
> choose to take when the user gives that indication.
> 
> Consider something like a screensaver.  Usually, the longer latency the 
> wakeup operation is, the longer the screensaver waits before deciding to, 
> say, power the monitor off, or put the system into suspend (as we 
> discussed that Mac OS X does at LinuxCon Boston).  Similarly, if there is 
> some background task that really needs to run, an intelligent system will 
> not allow a power economization mode to prevent that from happening.
> 
> > and (2) that it is supposed to ignore wakeup signals from certain
> > sources. 
> 
> Isn't this configurable now without system suspend with the wakeup sources 
> code?

The wakeup code does two things: It tells the system which devices 
should be enabled for wakeup when the system sleeps (as opposed to 
cpuidle, when all devices should be able to generate interrupts), and 
it tells the system when a wakeup event has just occurred so that the 
system won't allow itself to go to sleep before the event can be 
processed.

> > As I said, support for system suspend allows the user to do more with the
> > system and you really can't implement that functionality differently.  You
> > may choose not to implement it at all, but why should you?
> 
> The individual components of system suspend are definitely useful:
> 
> 1. preventing userspace processes from keeping the system from entering 
>    idle
> 2. preventing userspace processes from waking the system back up

It's not clear what this means.  How can a user process wake the system 
up?  Are you referring to user timers?

Do we have a way (or want a way) to distinguish between user timers and
kernel timers?

> 3. preventing kernel code from keeping the system from entering idle

Relatively few kernel threads are freezable.  The ones that are tend to 
be involved in device management.  Did you have something specific in 
mind?

> 4. preventing kernel code from waking the system back up
> 5. requesting that drivers abort what they are currently doing

Not exactly "abort".  More like "stop processing their I/O queues".

> The main issues are that these:
> 
> 1. are all bundled up into one operation
> 
> 2. target the entire universe of entities that they manage, rather than 
> selectively targeting non-power-privileged entities

That's an interesting way of thinking about it.  Thanks for bringing 
it up.

Alan Stern

Re: Runtime PM discussion notes

[Paul Walmsley]

(cc'ing some lists)

Hi

a few thoughts here:

On Wed, 15 Jun 2011, Rafael J. Wysocki wrote:

> On Tuesday, June 14, 2011, Magnus Damm wrote:
>
> > As for freezing user space, yes, I agree. The other feature including
> > a different set of wakeup sources, not so sure why you would want to
> > have that. I can't think of any good use case for that, from my point
> > of view system-wide suspend is more like the limping cousin of the
> > full-blown kernel.
> 
> Well, the freezing of user space by itself doesn't buy you anything
> power management-wise, you pretty much need to do the other things too to
> really save energy this way. 

Freezing user space stops CPU-hogging processes from running.  When the 
runqueue is empty, the scheduler can go idle.  This in turn allows the 
CPU(s) to enter low power sleep states via CPUIdle.

As I understand it, this is really the basis for the modern Android 
use-case for wakelocks and opportunistic suspend.  They prevent 
non-power-privileged userspace applications from keeping the system from 
entering a low-power state.  (Secondarily, suspend also prevents kernel 
code from running, e.g., timers set by filesystems, the networking stack, 
etc.; but problems here should be fixed in the offending kernel code, 
rather than hacked around, since some of the users of those timers could 
be important)

> Anyway, the value of system suspend is to allow the user to tell the system
> "OK, now I'm not going to use you for a while and I don't want the USB mouse
> to wake you up", so that the system can go into a state in which it draws
> minimum energy.
> 
> Of course, you can argue that the system may detect when it's not used and
> put itself into that state, which is somewhat correct, but the system can
> _never_ know two things by itself: (1) that it's not going to be used _in_
> _advance_

But suspend users don't know this either, since they can't predict when 
the next external wakeup can happen.

Having some kind of indication that the user is done using a device for 
the time being is definitely useful.  But that's separate from system 
suspend.  System suspend is just one of many actions that the system might 
choose to take when the user gives that indication.

Consider something like a screensaver.  Usually, the longer latency the 
wakeup operation is, the longer the screensaver waits before deciding to, 
say, power the monitor off, or put the system into suspend (as we 
discussed that Mac OS X does at LinuxCon Boston).  Similarly, if there is 
some background task that really needs to run, an intelligent system will 
not allow a power economization mode to prevent that from happening.

> and (2) that it is supposed to ignore wakeup signals from certain
> sources. 

Isn't this configurable now without system suspend with the wakeup sources 
code?

> As I said, support for system suspend allows the user to do more with the
> system and you really can't implement that functionality differently.  You
> may choose not to implement it at all, but why should you?

The individual components of system suspend are definitely useful:

1. preventing userspace processes from keeping the system from entering 
   idle
2. preventing userspace processes from waking the system back up
3. preventing kernel code from keeping the system from entering idle
4. preventing kernel code from waking the system back up
5. requesting that drivers abort what they are currently doing

The main issues are that these:

1. are all bundled up into one operation

2. target the entire universe of entities that they manage, rather than 
selectively targeting non-power-privileged entities


- Paul