Re: suspend blockers & Android integration

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday 06 June 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Sunday 06 June 2010, Arve Hjønnevåg wrote:
> >> 2010/6/5 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
> >> >> 2010/6/4 Matt Helsley <matthltc@us.ibm.com>:
> >> >> > On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
> >> >> >> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> >> >> > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
> >> >> >
> >> >> > <snip>
> >> >> >
> >> >> >>
> >> >> >> >     With the cgroup freezer you can "suspend" them right away and
> >> >> >> >     just keep the trusted background task(s) alive which allows us to
> >> >> >> >     go into deeper idle states instead of letting the crapplications
> >> >> >> >     run unconfined until the download finished and the suspend
> >> >> >> >     blocker goes away.
> >> >> >> >
> >> >> >>
> >> >> >> Yes this would be better, but I want it in addition to suspend, not
> >> >> >> instead of it. It is also unclear if our user-space code could easily
> >> >> >> make use of it since our trusted code calls into untrusted code.
> >> >> >>
> >> >> >
> >> >> > Perhaps I'm misunderstanding, but suspend and the cgroup freezer
> >> >> > interoperate well today -- you don't have to choose one or the other.
> >> >> > If you've discovered otherwise I'd consider it a bug and would like to
> >> >> > hear more about it.
> >> >> >
> >> >>
> >> >> I'm not aware of any bug with combining both, but we cannot use
> >> >> suspend at all without suspend blockers in the kernel (since wakeup
> >> >> events may be ignored)
> >> >
> >> > The more I think of it, the more it appears to me that the problem of
> >> > lost wakeup events can actually be solved without suspend blockers.
> >> > I'll send a bunch of patches to address this issue, probably tomorrow.
> >> >
> >>
> >> I know of two ways to prevent lost wakeup events. Reset a timeout
> >> every time you receive a wakeup event or prevents suspend until you
> >> know the event has been fully processed. Does your solution fall onto
> >> one of these two categories, or do you have a third way?
> >
> > Basically, it involves two mechanisms, detection of wakeup events occuring
> > right before suspend is started
> 
> This sounds like the timeout approach which I thought you did not like.
> 
> > and aborting suspend if wakeup events occur
> > in the middle of it.
> >
> Aborting suspend is easy, but when do you allow suspend again?

I would recommend you to wait for the patches and then comment. :-)

> >> >> and I don't know how we can safely freeze
> >> >> cgroups without funneling all potential wakeup events through a
> >> >> process that never gets frozen.
> >> >
> >> > If your untrusted apps get called by the trusted ones, they aren't really
> >> > untrusted in the first place.
> >> >
> >> That is not a correct statement. A trusted apps can call into an
> >> untrusted app, it just has to validate the response and handle not
> >> getting a response at all. There are also different levels of trust. I
> >> may have trusted an app to provide a contact pictures, but not trusted
> >> it to block suspend. When the phone rings the app will be called to
> >> provide the picture for the incoming call dialog, but if it is frozen
> >> at this point the more trusted app that handles the incoming phone
> >> call will not be able to get the picture.
> >
> > It will be able to do that if it causes the frozen part of user space to be
> > thawed.
> >
> > I think you have this problem already, though, because you use full system
> > suspend and all of your apps are frozen by it.  So, to handle the situation you
> > describe above, you need to carry out full system resume that will thaw the
> > tasks for you.  I don't see any fundamental difference betwee the two cases.
> >
> 
> Yes, we can keep all our user space suspend blockers and thaw the
> frozen cgroup when any suspend blocker is held, but this would
> eliminate any power advantage that freezing a cgroup has over using
> suspend to freeze all processes.

Why does it have to have _any_ power advantage?  It's totally sufficient if it
gives you approximately the same power savings.  IOW, it doesn't have to be
_better_ if it's acceptable to the kernel people at  large.

The rest of your objections have been addressed by Alan, so I'm not going to
repeat his arguments.

Rafael