lkml.org 
[lkml]   [2010]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: suspend blockers & Android integration
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:

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

The driver annotations don't need to block the cgroup freezing. They
just need to keep the system running long enough to awaken a thread
that will handle the wakeup event. (See below.) A pm-qos constraint
is good enough for this.

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

You can solve this problem if you restructure your "trusted" apps in
the right way. Require a trusted app to guarantee that whenever it
doesn't hold any suspend blockers, it will do nothing but wait (in a
poll() system call for example) for a wakeup event. When the event
occurs, it must then activate a suspend blocker.

Better yet, make it more fine-grained. Instead of trusted apps, have
trusted threads. Freeze the untrusted threads along with everything
else, and require the trusted threads to satisfy this guarantee.

In this way, while the system is idle no user timers will get renewed.
Kernel timers are another matter, but we should be able to handle them.
There's nothing Android-specific about wanting to reduce kernel timer
wakeups while in a low-power mode.

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

This is an entirely different matter from the rest of the discussion.
It would be better to consider this separately after Android's current
problems have been addressed.

Alan Stern

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

\
 
 \ /
  Last update: 2010-06-06 04:51    [W:0.148 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site