Re: [PATCH 0/8] Suspend block api (version 8)

Re: [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> This patch series adds a suspend-block api that provides the same
>> functionality as the android wakelock api. This version adds a
>> delay before suspending again if no suspend blockers were used
>> during the last suspend attempt.
>
>Patches [1-6/8] applied to suspend-2.6/linux-next

funny thing is that even without sorting out the concerns plenty of 
developers had on the other thread, this series is still taken. What's 
the point in dicussing/reviewing the patches then ?

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Monday 24 May 2010, Felipe Balbi wrote:
> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> This patch series adds a suspend-block api that provides the same
> >> functionality as the android wakelock api. This version adds a
> >> delay before suspending again if no suspend blockers were used
> >> during the last suspend attempt.
> >
> >Patches [1-6/8] applied to suspend-2.6/linux-next
> 
> funny thing is that even without sorting out the concerns plenty of 
> developers had on the other thread, this series is still taken. What's 
> the point in dicussing/reviewing the patches then ?

I don't think the concerns you're referring to can be solved out.  Some people
just don't like the whole idea and I don't think there's any way we can improve
the patches to make them happy.  The only "solution" they would be satisfied
with would simply be rejecting the feature altogether, although there are no
practically viable alternatives known to me.

OTOH I do think there are quite a few reasons to take the patchset, so I'm
going to push it to Linus as I told in one of my replies to Kevin.  If Linus
decides not to pull it, so be it.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Monday 24 May 2010, Felipe Balbi wrote:
>> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> >> This patch series adds a suspend-block api that provides the same
>> >> functionality as the android wakelock api. This version adds a
>> >> delay before suspending again if no suspend blockers were used
>> >> during the last suspend attempt.
>> >
>> >Patches [1-6/8] applied to suspend-2.6/linux-next
>> 
>> funny thing is that even without sorting out the concerns plenty of 
>> developers had on the other thread, this series is still taken. What's 
>> the point in dicussing/reviewing the patches then ?
>
> I don't think the concerns you're referring to can be solved out.  
> Some people just don't like the whole idea and I don't think there's
> any way we can improve the patches to make them happy.  The only
> "solution" they would be satisfied with would simply be rejecting
> the feature altogether, although there are no practically viable
> alternatives known to me.

I'm not sure who the "some people" you're referring to are, but I'll
assume I'm included in that group.

I don't think this is a fair characterization of the objections, nor
do I think "rejecting the feature altogether" is the only satisfactory
answer.  Speaking for myself, I find the idea of being able to suspend
while idle a valid objective, and certainly see the usefulness of it
for embedded systems.  I'm also an owner and user of an Android phone,
so I am certainly not out just to make life difficult for Android.

The primary objection is not the end goal, but rather the
implementation.  In particular, the problematic redefintion of what it
means to be idle, or "not doing work that's immediately useful to the
user" to use the phrase from the changelog (where "useful" is still
not defined.)

This (re)definition completely bypasses all current idle
infrastructure based on timers, scheduler, etc. and makes "usefulness"
defined in terms of who holds suspend blockers.  This of course will
lead to a scattering of suspend blockers into any drivers/subsystems
considered "useful", which by looking through current Android kernels
is many of them.

Kevin

Re: [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Tuesday 25 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Monday 24 May 2010, Felipe Balbi wrote:
> >> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> >> This patch series adds a suspend-block api that provides the same
> >> >> functionality as the android wakelock api. This version adds a
> >> >> delay before suspending again if no suspend blockers were used
> >> >> during the last suspend attempt.
> >> >
> >> >Patches [1-6/8] applied to suspend-2.6/linux-next
> >> 
> >> funny thing is that even without sorting out the concerns plenty of 
> >> developers had on the other thread, this series is still taken. What's 
> >> the point in dicussing/reviewing the patches then ?
> >
> > I don't think the concerns you're referring to can be solved out.  
> > Some people just don't like the whole idea and I don't think there's
> > any way we can improve the patches to make them happy.  The only
> > "solution" they would be satisfied with would simply be rejecting
> > the feature altogether, although there are no practically viable
> > alternatives known to me.
> 
> I'm not sure who the "some people" you're referring to are, but I'll
> assume I'm included in that group.
> 
> I don't think this is a fair characterization of the objections, nor
> do I think "rejecting the feature altogether" is the only satisfactory
> answer.  Speaking for myself, I find the idea of being able to suspend
> while idle a valid objective, and certainly see the usefulness of it
> for embedded systems.  I'm also an owner and user of an Android phone,
> so I am certainly not out just to make life difficult for Android.
> 
> The primary objection is not the end goal, but rather the
> implementation.  In particular, the problematic redefintion of what it
> means to be idle, or "not doing work that's immediately useful to the
> user" to use the phrase from the changelog (where "useful" is still
> not defined.)

So, in fact, you don't like the _idea_, because the _idea_ is to use suspend
blockers instead of trying to define what "idle" means.

I don't think it's generally possible to define "idle" to match every possible
criteria one can imagine, so you're request to do that simply cannot be
satisfied.

> This (re)definition completely bypasses all current idle
> infrastructure based on timers, scheduler, etc. and makes "usefulness"
> defined in terms of who holds suspend blockers.

That's because the point is not to suspend when the system is "idle", because
that would mean "suspend transparently from the applications' point of view",
which is what the Android people _don't_ _want_ _to_ _do_, because in that
case their battery life would go to the toilet.  The idea is to suspend even
when the system is not techincally "idle" and you don't like _that_.

> This of course will lead to a scattering of suspend blockers into any
> drivers/subsystems considered "useful", which by looking through current
> Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power
to reject requested changes.

As I said before, I don't think there's a way to resolve this so that everyone
is happy and in my opinion there are reasons to merge the feature.

Also I don't think we can make any progress discussing it.  We've already
discussed it for a month or so without any real progress and I don't see how
that's going to change now.

Thanks,
Rafael

Re: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > This of course will lead to a scattering of suspend blockers into any
> > drivers/subsystems considered "useful", which by looking through current
> > Android kernels is many of them.
> 
> That depends on the maintainers of these subsystems, who still have the power
> to reject requested changes. 

So as a scheduler maintainer I'm going to merge a patch that does a
suspend_blocker when the runqueue's aren't empty... how about that?

Re: [PATCH 0/8] Suspend block api (version 8)

[Arve Hjønnevåg]

On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> > This of course will lead to a scattering of suspend blockers into any
>> > drivers/subsystems considered "useful", which by looking through current
>> > Android kernels is many of them.
>>
>> That depends on the maintainers of these subsystems, who still have the power
>> to reject requested changes.
>
> So as a scheduler maintainer I'm going to merge a patch that does a
> suspend_blocker when the runqueue's aren't empty... how about that?
>

I don't know if you are serious, since the all the runqueues are never
empty while suspending, this would disable opportunistic suspend
altogether.

-- 
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: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> >> > This of course will lead to a scattering of suspend blockers into any
> >> > drivers/subsystems considered "useful", which by looking through current
> >> > Android kernels is many of them.
> >>
> >> That depends on the maintainers of these subsystems, who still have the power
> >> to reject requested changes.
> >
> > So as a scheduler maintainer I'm going to merge a patch that does a
> > suspend_blocker when the runqueue's aren't empty... how about that?
> >
> 
> I don't know if you are serious, since the all the runqueues are never
> empty while suspending, this would disable opportunistic suspend
> altogether.

So why again was this such a great scheme? Go fix your userspace to not
not run when not needed.
--
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: [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
>> On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend blockers into any
>> >> > drivers/subsystems considered "useful", which by looking through current
>> >> > Android kernels is many of them.
>> >>
>> >> That depends on the maintainers of these subsystems, who still have the power
>> >> to reject requested changes.
>> >
>> > So as a scheduler maintainer I'm going to merge a patch that does a
>> > suspend_blocker when the runqueue's aren't empty... how about that?
>> >
>>
>> I don't know if you are serious, since the all the runqueues are never
>> empty while suspending, this would disable opportunistic suspend
>> altogether.
>
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.


Thanks for your constructive feedback.

Brian

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 11:45:06 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
> > On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
> > >> > This of course will lead to a scattering of suspend blockers into any
> > >> > drivers/subsystems considered "useful", which by looking through current
> > >> > Android kernels is many of them.
> > >>
> > >> That depends on the maintainers of these subsystems, who still have the power
> > >> to reject requested changes.
> > >
> > > So as a scheduler maintainer I'm going to merge a patch that does a
> > > suspend_blocker when the runqueue's aren't empty... how about that?
> > >
> > 
> > I don't know if you are serious, since the all the runqueues are never
> > empty while suspending, this would disable opportunistic suspend
> > altogether.
> 
> So why again was this such a great scheme? Go fix your userspace to not
> not run when not needed.

Hi Peter!

This was already mentioned in one of these threads. 

The summary is: The device this kernel is running on dosn't want to
(or can) rely on userspace to save power. This is because it is an open
system, without an app-store or the like. Everyone can run what he
wants.

So anything relying on (all) userspace solves a different problem.

Cheers,
Flo




> --
> 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
> 


--
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: [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.
> 
> So anything relying on (all) userspace solves a different problem.

So what stops an application from grabbing a suspend blocker?

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 12:08:04 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 12:02 +0200, Florian Mickler wrote:
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> > 
> > So anything relying on (all) userspace solves a different problem.
> 
> So what stops an application from grabbing a suspend blocker?

Well, I don't own any android devices, but  If I read this all
correctly, an app can request the permission to grab an suspend blocker
at installation time. ("This application is requesting permission to
keep the device from sleeping, thus possibly reducing your battery
time. Are you shure you want to continue? [Yes,No]")

every app grabbing a suspend blocker is showing
up in a "these programs stop suspend" kind of battery-app and are thus
well accounted for. _And the user knows who to blame_.

Maybe this is implemented via fs-permissions? Anyway, I'm shure,
that the access control uses a well established method. :)  

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 12:02 PM, Florian Mickler <florian@mickler.org> wrote:

>> So why again was this such a great scheme? Go fix your userspace to not
>> not run when not needed.
>
> Hi Peter!
>
> This was already mentioned in one of these threads.
>
> The summary is: The device this kernel is running on dosn't want to
> (or can) rely on userspace to save power. This is because it is an open
> system, without an app-store or the like. Everyone can run what he
> wants.

I don't see this as a valid point. Everyone can run a different kernel
where nothing will just work. Are you aiming protection against that
as well?

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 13:18:51 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 12:02 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> >> So why again was this such a great scheme? Go fix your userspace to not
> >> not run when not needed.
> >
> > Hi Peter!
> >
> > This was already mentioned in one of these threads.
> >
> > The summary is: The device this kernel is running on dosn't want to
> > (or can) rely on userspace to save power. This is because it is an open
> > system, without an app-store or the like. Everyone can run what he
> > wants.
> 
> I don't see this as a valid point. Everyone can run a different kernel
> where nothing will just work. Are you aiming protection against that
> as well?
> 
> ~Vitaly

This is not "protection". This is functioning properly in a real world
scenario. Why would the user change the kernel, if the device would be
buggy after that? (Except maybe he is a geek)

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 1:37 PM, Florian Mickler <florian@mickler.org> wrote:

> This is not "protection". This is functioning properly in a real world
> scenario. Why would the user change the kernel, if the device would be
> buggy after that? (Except maybe he is a geek)

Hmm... Why would the user continue to use the program if it slows down
his device and sucks the battery as a vampire (Except maybe he's a
moron)? ;)

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:01:49 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 1:37 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > This is not "protection". This is functioning properly in a real world
> > scenario. Why would the user change the kernel, if the device would be
> > buggy after that? (Except maybe he is a geek)
> 
> Hmm... Why would the user continue to use the program if it slows down
> his device and sucks the battery as a vampire (Except maybe he's a
> moron)? ;)
> 
> ~Vitaly

Because he is using a robust kernel that provides suspend blockers and
is preventing the vampire from sucking power? 

Most users don't even grasp the simple concept of different "programs".
They just have a device and click here and there and are happy. 

Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)

And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
you prefer? I mean really... this is ridiculous. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

hi,

On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
>And if you have two kernels, one with which your device is dead after 1
>hour and one with which your device is dead after 10 hours. Which would
>you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good 
power management even for badly written applications. They should work, 
of course, but there's no assumption that the kernel should cope with 
those applications and provide good battery usage on those cases.

You can install and run anything on the device, and they will work as 
they should (they will be scheduled and will be processed) but you can't 
expect the kernel to prevent that application from waking up the CPU 
every 10 ms simply because someone didn't think straight while writting 
the app.

-- 
balbi

DefectiveByDesign.org

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> hi,
> 
> On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> >And if you have two kernels, one with which your device is dead after 1
> >hour and one with which your device is dead after 10 hours. Which would
> >you prefer? I mean really... this is ridiculous.
> 
> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.
> 
> You can install and run anything on the device, and they will work as 
> they should (they will be scheduled and will be processed) but you can't 
> expect the kernel to prevent that application from waking up the CPU 
> every 10 ms simply because someone didn't think straight while writting 
> the app.
> 

But then someone at the user side has to know what he is doing. 

I fear, if you target mass market without central distribution
channels, you can not assume that much.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
>But then someone at the user side has to know what he is doing.
>
>I fear, if you target mass market without central distribution
>channels, you can not assume that much.

and that's enough to push hacks into the kernel ? I don't think so. Do 
it like apple and prevent multi-tasking for any non-apple applications 
:-p

-- 
balbi

DefectiveByDesign.org

Re: [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:35:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> Hi,
> 
> On Wed, May 26, 2010 at 02:33:23PM +0200, ext Florian Mickler wrote:
> >But then someone at the user side has to know what he is doing.
> >
> >I fear, if you target mass market without central distribution
> >channels, you can not assume that much.
> 
> and that's enough to push hacks into the kernel ? I don't think so. Do 
> it like apple and prevent multi-tasking for any non-apple applications 
> :-p
> 
:) 

It really comes down to a policy decision by the distribution maker.
And I don't think kernel upstream should be the one to force one way or
the other. So merging this patch set will allow android to continue
their work _on mainline_ while everybody else can continue as before.

All points about the impact on the kernel have already been raised. So
you should be happy there. 

Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.

Also I expect there to be synergies between android development and
mainline kernel development _only_ if android development can use
mainline kernel.

And as for the quality of the "hack": I think you find this ugly, just
because you don't like the concept of degrading user space guaranties on
timers and stuff. 

But look at it this way: Suspend blockers are a way for the kernel
to make user space programs accountable for using the resource "power".
If a user space program needs the "traditional" guaranties for
functioning properly, it needs to take a suspend blocker. But _THEN_ it
better be well behaved. This is a kind of contract between userspace
and kernelspace.

On the other hand, if I don't need these traditional guaranties on
timers and stuff, I don't have to know device specific things about
power consumption. I can just use whatever facilities the programming
language provides without needing to worry about low level details.

This is a _big_ plus for attracting 3rd party programs. (And of course
the thing you don't like). 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:54 +0200, Florian Mickler wrote:

> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other.

That's exactly what we always do. If we were not to do so, the kernel
would be a bloated incoherent piece of crap.

>  So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

I really think we should not do so. Let them help in fixing the real
issue instead of creating a new class of userspace that is more
important than another.

> But look at it this way: Suspend blockers are a way for the kernel
> to make user space programs accountable for using the resource "power".

How is userspace without suspend blockers not accountable? We can easily
account runtime and in fact have several ways to do so.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

That seems to me to be conflating models of behaviour and implementations.

> This is a _big_ plus for attracting 3rd party programs. (And of course
> the thing you don't like). 

You would do better to concentrate on technical issues that the
assignment of malicious intent to other parties.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:19:42 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:


> > This is a _big_ plus for attracting 3rd party programs. (And of course
> > the thing you don't like). 
> 
> You would do better to concentrate on technical issues that the
> assignment of malicious intent to other parties.
> 
> Alan

This was nothing the kind of! He explicitly said this:

On Wed, 26 May 2010 15:29:32 +0300
Felipe Balbi <felipe.balbi@nokia.com> wrote:

> What I find ridiculous is the assumption that kernel should provide good 
> power management even for badly written applications. They should work, 
> of course, but there's no assumption that the kernel should cope with 
> those applications and provide good battery usage on those cases.

And I responded that if the kernel would do this, then that would
be a "_big_ plus for attracting 3d party programs". 

I had no intent in attacking anyone or putting word's in someones mouth.
Sorry if this was unclearly written.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Wed, May 26, 2010 at 3:54 PM, Florian Mickler <florian@mickler.org> wrote:
> It really comes down to a policy decision by the distribution maker.
> And I don't think kernel upstream should be the one to force one way or
> the other. So merging this patch set will allow android to continue
> their work _on mainline_ while everybody else can continue as before.
>
> All points about the impact on the kernel have already been raised. So
> you should be happy there.
>
> Nonetheless, I really think the kernel needs to allow for the android
> way of power saving. It misses out on a big feature and a big user-base
> if not.

Let's get rid of hypothetical uses in the future: suspend blockers is
_only_ used by Android user-space. Nobody else has expressed any
intention of using them.

> Also I expect there to be synergies between android development and
> mainline kernel development _only_ if android development can use
> mainline kernel.

That's like saying "there can only be synergies between linux real
time and mainline _only_ if RT development can use mainline".

I can give you my experience at Nokia... can you use mainline on any
of the Maemo devices? No. You have to patch the kernel heavily, to be
able to kind-of run the official user-space, or you have to use a
different user-space.

Does that prevent synergies? No. As Brian Swetland and Daniel Walker
already expressed before; you can run mainline kernel with debian on
Android phones.

It would be nice to run Android user-space, or parts of it on mainline
kernels, but if it's not possible, that's a deficiency on Android's
design; Maemo/Moblin/Meego are good players in the linux ecosystem so
you can re-use parts of the system on typical desktops (in fact many
are coming from there), and there are community distributions re-using
those parts and running just fine on mainline kernels.

Sure, it would be easier for Android developers if all their crap was
in the mainline, but even then there are no guarantees of anything.
Just like any other linux phone, you'll probably need to add patches
for 3D drivers, DSP, or other hardware acceleration, missing
board-specfic patches, and bunch of hacks.

So if you have to add all those patches anyway, what's the problem of
having to add the suspend block patches?

Why do some Android developers think they can be the exception and
have patches merged in the core of linux _only_ for their specific
user-space, and their specific drivers?

If you separate suspend blockers from Android, and judge them on their
technical merit, I don't see a single person saying this is a good
idea, we'll switch all our user-space to use them.

-- 
Felipe Contreras

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 15:29:32 +0300
> Felipe Balbi <felipe.balbi@nokia.com> wrote:
> 
> > hi,
> > 
> > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > >And if you have two kernels, one with which your device is dead after 1
> > >hour and one with which your device is dead after 10 hours. Which would
> > >you prefer? I mean really... this is ridiculous.
> > 
> > What I find ridiculous is the assumption that kernel should provide good 
> > power management even for badly written applications. They should work, 
> > of course, but there's no assumption that the kernel should cope with 
> > those applications and provide good battery usage on those cases.
> > 
> > You can install and run anything on the device, and they will work as 
> > they should (they will be scheduled and will be processed) but you can't 
> > expect the kernel to prevent that application from waking up the CPU 
> > every 10 ms simply because someone didn't think straight while writting 
> > the app.
> > 
> 
> But then someone at the user side has to know what he is doing. 
> 
> I fear, if you target mass market without central distribution
> channels, you can not assume that much.

Provide the developers and users with tools. 

Notify the users that their phone is using power at an unadvised rate
due to proglet $foo.

Also, if you can integrate into the development environment and provide
developers instant feedback on suckage of their app they can react and
fix before letting users run into the issue.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:41:29 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 14:33 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 15:29:32 +0300
> > Felipe Balbi <felipe.balbi@nokia.com> wrote:
> > 
> > > hi,
> > > 
> > > On Wed, May 26, 2010 at 02:24:30PM +0200, ext Florian Mickler wrote:
> > > >And if you have two kernels, one with which your device is dead after 1
> > > >hour and one with which your device is dead after 10 hours. Which would
> > > >you prefer? I mean really... this is ridiculous.
> > > 
> > > What I find ridiculous is the assumption that kernel should provide good 
> > > power management even for badly written applications. They should work, 
> > > of course, but there's no assumption that the kernel should cope with 
> > > those applications and provide good battery usage on those cases.
> > > 
> > > You can install and run anything on the device, and they will work as 
> > > they should (they will be scheduled and will be processed) but you can't 
> > > expect the kernel to prevent that application from waking up the CPU 
> > > every 10 ms simply because someone didn't think straight while writting 
> > > the app.
> > > 
> > 
> > But then someone at the user side has to know what he is doing. 
> > 
> > I fear, if you target mass market without central distribution
> > channels, you can not assume that much.
> 
> Provide the developers and users with tools. 
> 
> Notify the users that their phone is using power at an unadvised rate
> due to proglet $foo.
> 
> Also, if you can integrate into the development environment and provide
> developers instant feedback on suckage of their app they can react and
> fix before letting users run into the issue.
> 

Yeah. And I personally agree with you there. But this is a policy
decision that should not prevent android from doing it differently.
The kernel can not win if it does not try to integrate any use of it.
After all, we are a free comunity and if someone wants to use it their
way, why not allow for it? (As long as it does not directly impact other
uses)

The best solution wins, but not by decision of some kernel
development gatekeepers, but because it is superior. There are no clear
markings of the better solution. Time will tell.

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> The kernel can not win if it does not try to integrate any use of it.

If we'd integrate every patch that came to lkml, you'd run away
screaming.

We most certainly do not want to integrate _any_ use.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 15:07:27 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 15:03 +0200, Florian Mickler wrote:
> > The kernel can not win if it does not try to integrate any use of it.
> 
> If we'd integrate every patch that came to lkml, you'd run away
> screaming.
> 
> We most certainly do not want to integrate _any_ use.

We most certainly do want to integrate any use that is not harmful to
others.

I don't buy the argument that this is harmful. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Vitaly Wool]

On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian@mickler.org> wrote:

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
>
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous.

You almost always need to "hack" the mainline software for a
production system. So do it here as well. Make sure the hack is well
isolated and local. You can even submit it to the mainline, better as
a configuration option, _unless_ it is a *framework* that provokes
writing code in an ugly and unsafe way.

~Vitaly

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:55:31 +0200
Vitaly Wool <vitalywool@gmail.com> wrote:

> On Wed, May 26, 2010 at 2:24 PM, Florian Mickler <florian@mickler.org> wrote:
> 
> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> >
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous.
> 
> You almost always need to "hack" the mainline software for a
> production system. So do it here as well. Make sure the hack is well
> isolated and local. You can even submit it to the mainline, better as
> a configuration option, _unless_ it is a *framework* that provokes
> writing code in an ugly and unsafe way.
> 
> ~Vitaly

I don't think that the in-kernel suspend block is a bad idea. 

You could probably use the suspend-blockers unconditionally in the
suspend framework to indicate if a suspend is possible or not.
Regardless of opportunistic suspend or not. This way, you don't have to
try-and-fail on a suspend request and thus making suspending
potentially more robust or allowing for a "suspend as soon as
possible" semantic (which is probably a good idea, if you have to grab
your laptop in a hurry to get away).

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Stern]

On Wed, 26 May 2010, Florian Mickler wrote:

> I don't think that the in-kernel suspend block is a bad idea. 
> 
> You could probably use the suspend-blockers unconditionally in the
> suspend framework to indicate if a suspend is possible or not.

That's not how it works.  Drivers aren't supposed to abort
unconditional suspend -- not without a really good reason (for example,
the device received a wakeup event before it was fully suspended).  In
short, suspends should be considered to be _always_ possible.

> Regardless of opportunistic suspend or not. This way, you don't have to
> try-and-fail on a suspend request and thus making suspending
> potentially more robust or allowing for a "suspend as soon as
> possible" semantic (which is probably a good idea, if you have to grab
> your laptop in a hurry to get away).

That's different.  Suspend blockers could block (not abort!) regular 
suspends, just as they do opportunistic suspends.

But why should they?  I mean, if userspace wants to initiate a suspend
that is capable of being blocked by a kernel suspend blocker, then all
it has to do is initiate an opportunistic suspend instead of a normal
suspend.

Alan Stern

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 10:38:50 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 26 May 2010, Florian Mickler wrote:
> 
> > I don't think that the in-kernel suspend block is a bad idea. 
> > 
> > You could probably use the suspend-blockers unconditionally in the
> > suspend framework to indicate if a suspend is possible or not.
> 
> That's not how it works.  Drivers aren't supposed to abort
> unconditional suspend -- not without a really good reason (for example,
> the device received a wakeup event before it was fully suspended).  In
> short, suspends should be considered to be _always_ possible.
> 
> > Regardless of opportunistic suspend or not. This way, you don't have to
> > try-and-fail on a suspend request and thus making suspending
> > potentially more robust or allowing for a "suspend as soon as
> > possible" semantic (which is probably a good idea, if you have to grab
> > your laptop in a hurry to get away).
> 
> That's different.  Suspend blockers could block (not abort!) regular 
> suspends, just as they do opportunistic suspends.
> 
> But why should they?  I mean, if userspace wants to initiate a suspend
> that is capable of being blocked by a kernel suspend blocker, then all
> it has to do is initiate an opportunistic suspend instead of a normal
> suspend.
> 
> Alan Stern

Let me elaborate what i mean:

The assumption beeing that specifying pm constraints in the drivers is
a good thing which we will be doing anyway in the long run. 
(See Alan Cox's summary of current mainline problems[1].)

I don't wanna go into specifing any constraint API here, but it could
probably be either a blocker flag (the here presented suspend-blocker,
which Alan doesnt like?) 
or maybe a few integer-typed constraints defined by the pm-core.
(needed scheduler-latency/needed io-latency?)

As an intermediate step, it would probably be possible to
specify the "I cant be suspended" constraint (aka blocker) for all
drivers not explicitly stating anything other. 

Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any "no suspend" (or whatever) constraint before those
conditions arise and clearing of the constraints when it is no longer critical.  
(Much work.)

A future switch from something like a flag (blocker) to a
full integer-typed requirement would probably be a simple search and
replace or even possible by extending the blocker-api. 

If that is done, the prototype of the driver callback

int suspend(); 

could probably be changed to 

void suspend();

and it be expected to always _successfully_ suspend.

The hard part is finding the places where special guarantees are
needed. But android did show that this is possible.

Cheers,
Flo

[1]: http://lkml.org/lkml/2010/5/26/575

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Florian Mickler wrote:

>
> Converting a driver to using any constraint-API would require analysing
> what makes a driver refuse suspending in the old suspend handler and
> then specify any "no suspend" (or whatever) constraint before those
> conditions arise and clearing of the constraints when it is no longer critical.  
> (Much work.)
>   

That's not really true.
Nothing prevents using from the beginning a sane approach where drivers 
are required to specify constraints.

The way it has been done for the N900 was to let driver developers 
specify _very_ conservative constraints, during the conversion phase.

Then each driver has been optimized.

If you have as requirement for driver developers that their driver must 
be working properly when compiled as module, it is possible to test the 
system with a minimalistic kernel which enters the lowest power state as 
soon as possible, plus only those modules that are being optimized.

This allows also to identify parasitic drivers, which fail to apply the 
proper constraint and instead rely on some other driver to keep the 
system alive.

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Igor Stoppa]

ext Florian Mickler wrote:

>
> Converting a driver to using any constraint-API would require analysing
> what makes a driver refuse suspending in the old suspend handler and
> then specify any "no suspend" (or whatever) constraint before those
> conditions arise and clearing of the constraints when it is no longer critical.  
> (Much work.)
>   

That's not really true.
Nothing prevents using from the beginning a sane approach where drivers 
are required to specify constraints.

The way it has been done for the N900 was to let driver developers 
specify _very_ conservative constraints, during the conversion phase.

Then each driver has been optimized.

If you have as requirement for driver developers that their driver must 
be working properly when compiled as module, it is possible to test the 
system with a minimalistic kernel which enters the lowest power state as 
soon as possible, plus only those modules that are being optimized.

This allows also to identify parasitic drivers, which fail to apply the 
proper constraint and instead rely on some other driver to keep the 
system alive.

igor

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> Really, what are you getting at? Do you deny that there are programs,
> that prevent a device from sleeping? (Just think of the bouncing
> cows app)
> 
> And if you have two kernels, one with which your device is dead after 1
> hour and one with which your device is dead after 10 hours. Which would
> you prefer? I mean really... this is ridiculous. 

The problem you have is that this is policy. If I have the device wired
to a big screen and I want cows bouncing on it I'll be most upset if
instead it suspends. What you are essentially arguing for is for the
kernel to disobey the userspace. It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app
can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You
cannot solve a social problem with technology". In this case you have a
social/economic problem which is crap code. You solve it with an
economics solution - creative incentives not to produce crap code like
boxes that keep popping up saying "App XYZ is using all your battery" and
red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense
if you look at it from a different starting point. The starting point
being this: We have idling logic in the kernel and improving this helps
everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of
  suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is
  just a really deep idle in truth anyway) might break wakeups
  requirements because a device has wake dependencies due to hardware
  design (eg a port that has no electronics to kick the box out of
  suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the
phone runs the appstore code via something like

		setpidle(getpid(), something);
		exec()

where 'something' is a value with meaning to both user space and to the
existing idling logic in the kernel that basically says to what extent it
is permitted to block idling/suspend. That also seems to tie into some of
the realtime + idle problems. This I think deals with Kevin Hillman's
thoughts on dealing with untrustworthy app code more cleanly and avoids
the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in
their current situation they require that the power level doesn't drop
below some limit unless user requested. This is really important because
the platform vendor of the phone/pda/tablet whatever effectively owns the
kernel - so it's *their* problem, *their* control, *their* hardware and
they can make it work as best for the device. Best of all it means its
all free software stuff so if the vendor screws up you can still fix your
phone. 

Implementation-wise it probably ties into setpidle, its simply that a task
has a pair of idle values, a dynamic one and a base one, the dynamic one
being the base one but updatable temporarily by drivers.

Alan
--

[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. "Static" simply means it's not been made fast enough yet but
its just a policy divide dependant on the users 'acceptable' resume time
(which for hard RT may just as well rule out some more usual power states)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Alan,

On Wed, 26 May 2010, Alan Cox wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I completely agree. 

We have already proven that the social pressure on crappy applications
works. When NOHZ was merged into the kernel we got no effect at all
because a big percentage of user space applications just used timers
at will and without any thoughts, also it unveiled busy polling and
other horrible coding constructs. So what happened ? Arjan created
powertop which lets the user analyse the worst offenders in his
system. As a result the offending apps got fixed rapidly simply
because no maintainer wanted to be on top of the powertop sh*tlist.

In the mobile app space it's basically the same problem. Users can
influence the app writers simply by voting and setting up public lists
of apps which are crappy or excellent. All it needs is a nice powertop
tool for the phone which allows the users to identify the crap on
their phones. That provides much more incentive - especially for
commercial players - to fix their crappy code.

Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
is just counter productive as it signals to the app provider: Go
ahead, keep on coding crap!

That's not a solution, that's just capitulation. 

It's absurd that some folks believe that giving up the most efficient
tool to apply pressure to crappy app providers is a good idea.

Thanks,

	tglx

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Balbi]

Hi,

On Wed, May 26, 2010 at 03:46:55PM +0200, Thomas Gleixner wrote:
> > > Really, what are you getting at? Do you deny that there are programs,
> > > that prevent a device from sleeping? (Just think of the bouncing
> > > cows app)
> > > 
> > > And if you have two kernels, one with which your device is dead after 1
> > > hour and one with which your device is dead after 10 hours. Which would
> > > you prefer? I mean really... this is ridiculous. 
> > 
> > The problem you have is that this is policy. If I have the device wired
> > to a big screen and I want cows bouncing on it I'll be most upset if
> > instead it suspends. What you are essentially arguing for is for the
> > kernel to disobey the userspace. It's as ridiculous (albeit usually less
> > damaging) as a file system saying "Ooh thats a rude file name, the app
> > can't have meant it, I'll put your document soemwhere else"
> > 
> > The whole API feels wrong to me. It's breaking rule #1 of technology "You
> > cannot solve a social problem with technology". In this case you have a
> > social/economic problem which is crap code. You solve it with an
> > economics solution - creative incentives not to produce crap code like
> > boxes that keep popping up saying "App XYZ is using all your battery" and
> > red-amber-green powermeter scores in app stores.
> 
> I completely agree. 
> 
> We have already proven that the social pressure on crappy applications
> works. When NOHZ was merged into the kernel we got no effect at all
> because a big percentage of user space applications just used timers
> at will and without any thoughts, also it unveiled busy polling and
> other horrible coding constructs. So what happened ? Arjan created
> powertop which lets the user analyse the worst offenders in his
> system. As a result the offending apps got fixed rapidly simply
> because no maintainer wanted to be on top of the powertop sh*tlist.
> 
> In the mobile app space it's basically the same problem. Users can
> influence the app writers simply by voting and setting up public lists
> of apps which are crappy or excellent. All it needs is a nice powertop
> tool for the phone which allows the users to identify the crap on
> their phones. That provides much more incentive - especially for
> commercial players - to fix their crappy code.
> 
> Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel
> is just counter productive as it signals to the app provider: Go
> ahead, keep on coding crap!
> 
> That's not a solution, that's just capitulation. 
> 
> It's absurd that some folks believe that giving up the most efficient
> tool to apply pressure to crappy app providers is a good idea.

I couldn't agree more with both of you. I also have stated that a
powertop application with a fancy UI would do the job. Also building
some sort of power estimations on the SDK would allow the developer the
have fast feedback about potential power consumption caused by his app
on the device.

On top of that, the app stores can use the same power estimation
"technology" to rate apps automatically and even reject apps that are
waaaay too badly written.

I also feel that kernel shouldn't have to deal, fix, hide bad behavior
from apps.

-- 
balbi

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 14:16:12 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > Really, what are you getting at? Do you deny that there are programs,
> > that prevent a device from sleeping? (Just think of the bouncing
> > cows app)
> > 
> > And if you have two kernels, one with which your device is dead after 1
> > hour and one with which your device is dead after 10 hours. Which would
> > you prefer? I mean really... this is ridiculous. 
> 
> The problem you have is that this is policy. If I have the device wired
> to a big screen and I want cows bouncing on it I'll be most upset if
> instead it suspends. What you are essentially arguing for is for the
> kernel to disobey the userspace. It's as ridiculous (albeit usually less
> damaging) as a file system saying "Ooh thats a rude file name, the app
> can't have meant it, I'll put your document soemwhere else"
> 
> The whole API feels wrong to me. It's breaking rule #1 of technology "You
> cannot solve a social problem with technology". In this case you have a
> social/economic problem which is crap code. You solve it with an
> economics solution - creative incentives not to produce crap code like
> boxes that keep popping up saying "App XYZ is using all your battery" and
> red-amber-green powermeter scores in app stores.

I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.

<<If you want to use the rare resource "power" you have to take a
suspend blocker. By this you assert that you are a well written
application. If you are not well written, you will get the worst of our
red-amber-green powermeter scores we have.>>

On the other hand, applications can say, they don't need that much
power and userspace guaranties and not take a suspend blocker.

This is an option which they currently don't have.

I don't think opportunistic suspend is a policy decision by the kernel.
it is something new. Something which currently only the android
userspace implements / supports. If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and
make yourself a user-visible power-eater, or don't do 

echo "opportunistic" > /sys/power/policy 

in the first place.

This "optionally being badly written, who cares?" is a new feature the
kernel can provide to applications. 

That said, your proposed alternative implementation scheme looks like
another possible approach.


> That said if you want technical mitigation I think it makes more sense
> if you look at it from a different starting point. The starting point
> being this: We have idling logic in the kernel and improving this helps
> everyone. What is needed to improve the existing logic ?
> 
> - You don't know which processes should be ignored for the purpose of
>   suspend (except for kernel threads) and there is no way to set this
> 
> - You don't know whether a move from a deep idle to a 'suspend' (which is
>   just a really deep idle in truth anyway) might break wakeups
>   requirements because a device has wake dependencies due to hardware
>   design (eg a port that has no electronics to kick the box out of
>   suspend into running). This is a problem we have already. [1]
> 
> That maps onto two existing ideas
> 
> Sandboxing/Resource Limits: handling apps that can't be trusted. So the
> phone runs the appstore code via something like
> 
> 		setpidle(getpid(), something);
> 		exec()
> 
> where 'something' is a value with meaning to both user space and to the
> existing idling logic in the kernel that basically says to what extent it
> is permitted to block idling/suspend. That also seems to tie into some of
> the realtime + idle problems. This I think deals with Kevin Hillman's
> thoughts on dealing with untrustworthy app code more cleanly and avoids
> the need for userspace hackery like the blocker API.
> 
> And an entirely in kernel API where device drivers can indicate that in
> their current situation they require that the power level doesn't drop
> below some limit unless user requested. This is really important because
> the platform vendor of the phone/pda/tablet whatever effectively owns the
> kernel - so it's *their* problem, *their* control, *their* hardware and
> they can make it work as best for the device. Best of all it means its
> all free software stuff so if the vendor screws up you can still fix your
> phone. 
> 
> Implementation-wise it probably ties into setpidle, its simply that a task
> has a pair of idle values, a dynamic one and a base one, the dynamic one
> being the base one but updatable temporarily by drivers.
> 
> Alan

How does this address the loss of wakeup events while using suspend? 
(For example the 2 issues formulated by Alan Stern in [1])

cheers,
Flo

[1]http://lkml.org/lkml/2010/5/21/458

p.s.: 
dmk@schatten /usr/src/linux $ grep -r "setpidle" .
dmk@schatten /usr/src/linux $ 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > Implementation-wise it probably ties into setpidle, its simply that a task
> > has a pair of idle values, a dynamic one and a base one, the dynamic one
> > being the base one but updatable temporarily by drivers.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

By not suspending obviously.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

That's backwards.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:15:47 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > I'm not saying that your argument is not valid. But why don't you look
> > at suspend blockers as a contract between userspace and kernelspace? An
> > Opt-In to the current guarantees the kernel provides in the non-suspend
> > case.
> 
> That's backwards.

I think that's the point of it. 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> On Wed, 26 May 2010 17:15:47 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > I'm not saying that your argument is not valid. But why don't you look
> > > at suspend blockers as a contract between userspace and kernelspace? An
> > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > case.
> > 
> > That's backwards.
> 
> I think that's the point of it. 

Apparently, and you're not accepting that we're telling you we think its
a singularly bad idea. Alan seems to have the skill to clearly explain
why, I suggest you re-read his emails again.

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:45:00 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > On Wed, 26 May 2010 17:15:47 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > I'm not saying that your argument is not valid. But why don't you look
> > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > case.
> > > 
> > > That's backwards.
> > 
> > I think that's the point of it. 
> 
> Apparently, and you're not accepting that we're telling you we think its
> a singularly bad idea. Alan seems to have the skill to clearly explain
> why, I suggest you re-read his emails again.

I'm sorry if I offend you. I indeed read Alan's emails. It's just they
have more content than yours. So it takes longer. 

Cheers,
Flo

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Wed, 26 May 2010 17:47:35 +0200
Florian Mickler <florian@mickler.org> wrote:

> On Wed, 26 May 2010 17:45:00 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, 2010-05-26 at 17:40 +0200, Florian Mickler wrote:
> > > On Wed, 26 May 2010 17:15:47 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > > On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> > > > > I'm not saying that your argument is not valid. But why don't you look
> > > > > at suspend blockers as a contract between userspace and kernelspace? An
> > > > > Opt-In to the current guarantees the kernel provides in the non-suspend
> > > > > case.
> > > > 
> > > > That's backwards.
> > > 
> > > I think that's the point of it. 
> > 
> > Apparently, and you're not accepting that we're telling you we think its
> > a singularly bad idea. Alan seems to have the skill to clearly explain
> > why, I suggest you re-read his emails again.
> 
> I'm sorry if I offend you. I indeed read Alan's emails. It's just they
> have more content than yours. So it takes longer. 
> 
> Cheers,
> Flo

p.s.: also they encourage me to think more before answering. 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:
> If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
How about we don't merge that junk and don't give you the opportunity to
do silly things like that? :-)

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Alan Cox]

> I'm not saying that your argument is not valid. But why don't you look
> at suspend blockers as a contract between userspace and kernelspace? An
> Opt-In to the current guarantees the kernel provides in the non-suspend
> case.

It is a contract - but not the right one. You are removing autonomy from
the kernel when only the kernel can measure the full picture and when the
kernel is actually supposed to be responsible for resource management.

> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.

Even the the model is wrong.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android

Disagree. It's an arbitary and misleading divide that happens to reflect
a specific vendors current phones. Worse yet it may not reflect their own
future products. It assumes for example that their is some power level
that is 'suspend' that is singular, application understood and can be
effectively user space managed. Big assumptions and not ones that seem to
be sensible.

It also breaks another rule - when the hardware changes your application
blocker policies will be wrong. Do you want multiple hand optimised
copies of each app ? Take a look at what happened to CPU designs where
the assumption was you'd recompile the app for each CPU version to get
any useful performance.

If you are instead expressing it as "must be able to respond in time X"
and "must be able to wake up from an event on an active device" then your
interface is generic and hardware independant.

If "bouncing cows" says 'need to wake up every 0.3 seconds" you want the
kernel to decide how best to do that. It will vary by hardware. On todays
desktop PC thats probably a low power state limit. On some current
embedded hardware it might be a special deep sleep mode. On one or two
devices it might be 'suspend'. It might also be that the properties have
been set to 2 seconds already so it gets told it can't have 0.3.

The app cannot be allowed to know platform specific stuff or your
portability comes apart and you end up with a disaster area where each
app only comes on a subset of devices. Express the requirement right and
you get a simple clean interface that continues to work.

Express it wrong and you get a mess.

> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 

Thats a very big hammer and it doesn't express what I actually want,
which is to allow the cows to run as efficiently as possible.
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.

But you can do this properly by having a per process idle requirement,
and that can encompass things like hard real time as well (or even
gaming). The suspend blockers break all the global policy, don't solve
real time and don't allow for sensible expansion models. They don't solve
our existing wakeup versus device problems either.

> How does this address the loss of wakeup events while using suspend? 
> (For example the 2 issues formulated by Alan Stern in [1])

In this environment the problem cannot occur in the first place unless
there are kernel code bugs, if there are then they are in GPL code and can
be fixed. But you are mixing up interfaces and implementations which I
find is usually a bad idea. Doing the right thing badly gives you an
interface to an implementation you can later fix. Doing the wrong thing
well leaves you stuck down a hole.

> p.s.: 
> dmk@schatten /usr/src/linux $ grep -r "setpidle" .

Yes I know - no point having a new function which has an in use name is
there ? It's trivial to add per process idling or wakeup requirements.

Alan

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

Florian,

On Wed, 26 May 2010, Florian Mickler wrote:
>
> On the other hand, applications can say, they don't need that much
> power and userspace guaranties and not take a suspend blocker.
> 
> This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to
express that in various ways already today. Admittedly it's far from
perfect, but that can be fixed by adding interfaces which allow the
power aware coder to express the requirements of his application
actively, not by avoiding it.

suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.

Also they enforce a black and white scheme (suspend or run) on the
kernel which is stupid, as there are more options to efficiently save
power than those two. While current android devices might not provide
them, later hardware will have it and any atom based device has them
already.

So what the kernel needs to know to make better decisions are things
like:

  - how much slack can timers have (exisiting interface)
  - how much delay of wakeups is tolerated (missing interface)

and probably some others. That information would allow the kernel to
make better decisions versus power states, grouping timers, race to
idle and other things which influence the power consumption based on
the hardware you are running on.

> I don't think opportunistic suspend is a policy decision by the kernel.
> it is something new. Something which currently only the android
> userspace implements / supports. If you don't want to suspend while
> looking at the bouncing-cow, you have to take a suspend blocker and
> make yourself a user-visible power-eater, or don't do 
> 
> echo "opportunistic" > /sys/power/policy 
> 
> in the first place.
> 
> This "optionally being badly written, who cares?" is a new feature the
> kernel can provide to applications. 

It's a misfeature which the kernel should not provide at all. It sends
out the completely wrong message: Hey, we can deal with your crappy
code, keep on coding that way.

While this seems to sound cool to certain people in the mobile space,
it's completely backwards and will backfire in no time. 

The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.

Thanks,

	tglx