Date:	Sat, 5 Jun 2010 18:03:11 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Matt Helsley <matthltc@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend blockers & Android integration

2010/6/5 Rafael J. Wysocki <rjw@...k.pl>:
> On Sunday 06 June 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Rafael J. Wysocki <rjw@...k.pl>:
>> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
>> >> 2010/6/4 Matt Helsley <matthltc@...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@...utronix.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?

>> >> 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. Without annotating the drivers to
block the cgroup freezing in the same places as we now block suspend,
it also prevents processes in the cgroup that we freeze from directly
consuming wakup events.

>> > From what you're saying it follows that you're not really willing to accept
>> > any solution different to your suspend blockers.  Is that really the case?
>> >
>> I don't think that is a fair way to put it. We need to support our
>> user-space framework and I have not seen an alternative solution that
>> clearly will work (other than replacing suspend_blockers with pm_qos
>> constraints that do the same thing).
>
> Then think again of the approach I proposed and explain to me why it won't
> work, because I haven't seen any convincing argument on that yet.
>

If you are referring to the approach that we don't use suspend but
freeze a cgroup instead, this only solves the problem of bad apps. It
does not help pause timers in trusted user space code and in the
kernel, so it does not lower our average power consumption. And, it
does not solve the problem for systems that enters lower power states
from suspend than it can from idle. The last point my not be relevant
to android anymore, but desktop systems already have auto suspend and
it would be preferable to have a race free kernel api for this.

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

Powered by blists - more mailing lists